I’ve been using restic for probably 6-8 years, but it’s been solely on linux machines for offsite backups. I’ve recently found a use case for my windows daily-driver so I’m starting to mess with it. I came across a (possibly) interesting question so I figured I’d ask here…
My laptop runs windows 11 and WSL2. I’ve got a large-ish (terabyte or so) file set that I’d want to back up somewhere. n.b. - I’m aware that the filesystem performance from within WSL is substantially worse than native NTFS access, but I’m also FAR better at writing python and bash than I am writing PowerShell…
so I’m trying to figure out if doing something like… run the initial backup using the native windows / powershell client, and THEN switch over to WSL using the linux restic binary to do incremental snapshots from that point forward.
The idea here is that the snapshots will be a lot smaller than the initial, and I like the linux environment more. The directory is crossmounted from windows to WSL, so the actual files are the same, but I’m not at all sure whether the metadata or Other Magick Stuff will appear the same to the linux version of restic as it does to the windows version of restic.
And, yes, I will be testing this to see what happens … but I also figured I would ask here in case one of the developers or someone else has Useful Experience In These Things and might perhaps say “yes I do this all the time and it just works” or “yes this seems reasonable but here look out for this” or possibly even “this is the worst idea since a hard limit of 640KB RAM” …
I’ve a fair bit of experience with restic & WSL, but I wound up staying away from backing up windows files mainly due to “the performance problem” that you mentioned. That said, here are a few potential “gotcha’s” to a hybrid wsl/windows approach that I can think of:
The file metadata in WSL vs windows will be different enough that restic will treat all the files as though they are “new” in your first linux backup.
The file paths (and I think even the host too) will be different in WSL, so restic’s default forget grouping won’t group the windows and linux snapshots together. You could forget the initial windows snapshot by hand, once you have a linux snapshot, to solve this issue though.
The restic cache will be unique to each “OS”, so you’ll end up with a windows cache and a WSL cache. You may want to delete the windows cache after the initial windows snapshot is done.
You won’t have access to restic managed VSS snapshots like you would when running restic under windows. I’ve no idea if that’ll cause file access issues in practice; it’s not something I’ve personally tested.
I would expect scan speed will not be great from inside WSL. Even when the backup dataset hasn’t changed between backup runs, restic still has to read the metadata of each file to know what to back up. If your backup dataset is “one large file” this is probably not going to have any impact though!
When restoring, you’ll be restoring the files “as they were mounted in WSL”, rather than as they were in windows. I suspect there will be some windows file metadata loss as a result, but I couldn’t find a conclusive answer via search or the WSL documentation, and I haven’t tested this myself. I would strongly advise you to perform a test backup/restore, and verify that the restored files have all the metadata attributes you need/want from the windows-side before committing to this approach. Some relevant WSL documentation can be found here.
Unsolicited advice below; please disregard if you’re firmly set on doing the WSL method :
My personal opinion is that I would not use restic from within WSL except as a last resort; the trade-offs are too great for me.
You mentioned python experience; and python would be a good choice to script restic operations under windows in my opinion. However, if you wanted to avoid the pain of writing something yourself, there already exist many tools to manage restic. Some I have good experience with under windows specifically are prestic, and kmwoley’s powershell scripts. They both work slightly differently, but I can thoroughly recommend both. Obviously, other tools also exist (the community forum section has lots to choose from).
The above all said, if a bash/python script run under WSL works for you, then crack on Ultimately, all that matters is that your chosen solution works for your use case. Please do report back if you go the WSL route, I’d be interested to hear how it works out for you.
As I somewhat expected and feared, this reply is both awesome and terrible.
Awesome: it’s incredibly thorough, walks through lots of valid considerations, and is precisely why I like working with clueful folks who like putting their own solutions together from good opensource projects.
Terrible: it confirms a lot of my worries about the “cross platform” nature of what I’m trying to do. The pointer to kmwoley’s repo was incredibly useful, whether I end up using those as-are or leaning on them for help with rolling my own, I should have realized there would be a public repo out there somewhere that had a lot of what I needed.
I need to experiment some to figure out exactly how painful some of these things will end up being, but this give me a ton of useful info and context and a great head start on where to shine the flashlight first.
:
Ultimately, all that matters is that your chosen solution works for your use case. Please do report back if you go the WSL route, I’d be interested to hear how it works out for you.