I was looking to backup the data on my old laptop in case my drive ever failed or broke down. I used an external drive and backed up all my files according to restic’s instructions. Low and behold my drive did break and now I need to recover my data. I could restore it just find on my old laptop but on my new one I get an error for every single file. As it is I cannot retrieve my data and have been unable to find a solution online. Any help would be appreciated
Hi @okno,
From the G: above, I see you are on Windows, a ‘platform’ I avoid as much as I can.
But anyway, the reported paths all starting with \G\G:\ seem very strange, and I think pretty much ‘illegal’: I don’t think a ':' is tolerated anywhere on a Windows path except at its exact second character (ie, right after a drive letter, which must itself be the first character).
I would double-check that if I were you.
Cheers, and hope that helps,
– Durval.
Welcome to the forum!
You may have run into a bug. In order to diagnose it, can you please paste the complete command line you used to start restic?
If it’s a bug we’ll fix it so you can restore your data.
Hello,
The command I used to back my files up was the exact command restic -r /srv/restic-repo --verbose backup ~/work from the documentation, with the directories replaced respectively. I backed up my entire G drive.
The command I used to try to restore them was restic -r drivetwo-repo restore latest --target ...
I’m not sure if the issue is because when I backed up my data on another computer it was on the G: drive, and I am trying to back up the data onto my current computer’s G: drive.
Hello,
Thanks for the advice. It does seem that the path is illegal after you pointed it out. However, I am unsure on how to fix or edit the files to fix the path issue. If you are aware on how to do so, please let me know!
Humrmmrmmr… “~/work”… “~” in *ix systems expand to $HOME, but I did not know this was supposed to even work in Windows, but if did, it should expand to something like “C:\Users$USERNAME” or similar, definitely not to something like "\G\G:" with no “work” showing anywhere in the reported paths…
Anyway, the paths being reported seem to be the problem. I wonder how exactly they are stored in your repo. Can you please provide the first few lines of restic -r drivetwo-repo ls latest?
Cheers,
– Durval.
Hello again,
I probably should have specified I did not use ~work and instead used a path like C:/Users/drale/documents. Regardless, here is the output from restic -r drivetwo-repo ls latest.
Very interesting, from the screenshot:
snapshot [...] of [G:\]
The "G:" is, the way I understand it, the origin for your backup, ie the root of drive G: – and in fact it looks like a Windows machine root, to wit the “$RECYCLE.BIN” directory for the Windows trashcan on that drive.
But then, where the heck did your restic backup get the “/G/” that is prefixing each and every path shown by restic ls? This is definitely NOT the way it works on decen^H^H^H^H^Hnon-Windows OSes like MacOSX, Linux, BSD etc. I’m at a loss to understand that.
The reason for the errors during restore, OTH, is very clear: I just tested trying to create a similar file and it failed:
C:\Users\REDACTED>mkdir \c\c:test
The directory name is invalid.
This is certainly what restic restore gets from the OS when it tries to create such a path, and therefore why your restore is failing. The mistery is how that crazy “/G/” ‘prefix’ got there in the first place.
But anyway, I understand that restoring your backup is more important right now than finding the root cause of that issue. For restic restore to be able to create those dirs and files and therefore restore your backup, it would be necessary to somehow strip that "/G/ prefix from each and every pathname.
I know of no restic option that could do that; from what I can see, the only way to do that would either (a) incorporate some kind of “prefix-removal” option for restic restore (ie, something like -p 2 to strip up to and including the first “/”, the same way it works for example on patch(1) (you could perhaps open a “new feature” issue on restic’s github for that), or cook a special restic binary just for you that would do that very specific (ie, “/G/” removal).
Unfortunately my knowledge of both Go and the restic source code is not enough for either, if it was I would volunteer to help you with that.
Can/will someone else here more knowledgeable than me, please help @okno?
Cheers,
– Durval.
@okno, I just had the craziest idea: perhaps you can boot Linux in your computer (from some LiveDVD/LiveUSB image), mount your Windows partition, and then run restic there to do the recovering. This would work because “/G/G:/…” is not illegal on Linux. Then, after you restic restore finishes, you just rename the top-level dir, removing the ‘:’ (which is illegal on linux). Some basic symlinking will also be necessary to redirect /G/ to your Windows partition, something along the lines of what I just tested here:
# fdisk -l /dev/sda
[...]
/dev/sda4 1259520 249368686 248109167 118.3G Microsoft basic data
# mkdir -p /mnt2; mount /dev/sda4 /mnt2
# ln -s /mnt2 /G
# mkdir /G/G:/
# mkdir /G/G:/test
# 2005 ls -lR /G/G:
test
Good luck, and keep us posted!
Cheers,
– Durval.
@durval
Sounds crazy enough just to work! I don’t have enough time to do it right now but i’ll do it in the next day and update this post with the results. Thanks for the advice!
I’d suggest instead:
# mkdir /G
# ln -s /mnt2 /G/G:
Even on Linux, : is not a valid character on a Windows-formatted volume (FAT, NTFS, etc.).
This is not the test I showed above depicted: please notice I mounted an already existing Windows partition (as shown by the fdisk -l /dev/sda and the mkdir /G/G:/ succeeded without any errors nor warnings.
Cheers,
– Durval
Aha, this restriction must have been lifted for NTFS volumes somewhere along the line (this is not what I recall from years ago when NTFS support on Linux was still new-ish).
Regardless, this is still true for FAT volumes today.
# touch 'G:'
touch: setting times of 'G:': No such file or directory
Generally, I would recommend against creating anything with the : character on a volume that will be used by Windows, as I would not expect Windows tools to be able to deal with it. If this approach is taken, make sure that you move the content in /G/G: somewhere else and remove that directory before booting back into Windows.
Hence my suggestion to make /G/G: a symlink into a different directory on the Windows volume.
Thanks for the info. I posted re: NTFS because @okno was referring to his Windows partition, and AFAIK at least since Windows 2000, it always creates its partitions in NTFS format by default.
Great, one more thing for @okno to try 
And I agree with you, if creating paths with “:” in them can be avoided, it’s the best way forward.
Cheers,
– Durval.