Hello.
I’m having issues when trying to restore a snapshot and I can’t figure out what’s happening from the error messages:
…
repository c86b9751 opened successfully, password is correct
restoring <Snapshot 6302659f of [/home/ucibd27t /usermail/ucibd27t] at 2021-03-31 12:07:02.607823846 +0200 CEST by root@web-staging.dnshosting.local> to /
ignoring error for /home/ucibd27t/domains/esaurimental.it/public_html/presta/localization/CLDR/core/common/main/ccp.xml: UtimesNano: no such file or directory
ignoring error for /home/ucibd27t/domains/esaurimental.it/public_html/presta/localization/CLDR/core/common/main/cs.xml: UtimesNano: no such file or directory
…
Note that if I mount the snapshot with restic -r … mount, the files are there. Nevertheless they are not restored.
restic 0.10.0 compiled with go1.13.15 on linux/amd64
Can you help me to understand the problem?
Thanks a lot
I’m no developer and I don’t understand the error myself but can you try again with restic 0.12.0 (the most recent stable version)? Maybe this is a bug in GO or restic which has been fixed in newer versions.
I am having the exact same issue. I have made backups of my internal HDD containing all my data, which died yesterday. It is an old Windows drive so using ‘ntfs’ as filesystem. When trying to restore the data to another (internal) drive I face this issue.
I used this command to try restoring: restic -v -r /media/myUser/INTENSO/Daten/restic-repo_daten-partition restore latest --target /mnt/DataRestore/ --include /home/myUser/Daten
I also tried it without the --include option. Both do fail with this error for every single file and directory: ignoring error for /home: UtimesNano: no such file or directory (example for /home)
I want to mention that I tried it both, with my “old” restic 0.11.0 from debian sources and (as suggested above) with the latest version 0.12.1. Please also have in mind, that I created the snapshots with the --ignore-inode option since the ‘ntfs’ drive is mounted as fuseblk and though restic rescans the whole disk for every snapshot if the option is omitted.
Does anyone know if and how I can restore the data (besides using the fuse mount, what I am currently trying)?
I used the fuse mount option and copied the data from the virtual fuse drive. This way I was able to restore my data (almost complete, as far as I was able to check it).
Nevertheless I would like to know if and how I can restore data with the classic restore command or at least what is the reason why I can not.
My impression was that using the fuse option and copy data with cp or rsync is relatively slow (around twice the time for full backup), but maybe that is a false impression and restoring is always kind of “slow” in return to the high compression?
These error messages shouldn’t prevent the restore operation from succeeding. Actually the worst thing that error could cause is that the file timestamps are wrong. So did restic restore anything?
Copying from a mounted directory is much slower than the restore operation. With a fuse mount each file has to be copied one after another, whereas restore knows the whole list of files to restore and can access all data in the fastest way possible.
I did not found any restored files on my replacement drive, so I would answer “no”. The error occurred for some 400000 files in roughly five seconds and then the restore operation finished with something like “400000 errors, no successful”.
Since it was already some days ago, I do not remember everything exactly (and stupidly I have not saved the command and output - SORRY!). I actually consider right now if I maybe had insufficient permissions to write to the drive (which could have probably been the real error). But there definitely was no message visible to me, indicating anything related to insufficient permissions/writing problems. Else I would have payed special attention to it. If there has been such error message it must have occurred before the UtimesNano errors and then been dumped from the terminal output (due to the enormous number of UtimesNano errors). Else there has not been such message.
Ok, so I carried out some (more) tests to prevent me from having this “issue” again.
It seems I have to admit that it was my fault: It is impossible to restore a snapshot to a directory I do not have writing permission to (obviously).
As a default user I mounted an exFAT partition to a freshly created directory unter /mnt using sudo mount /dev/sdd1 /mnt/newDir. This results in the partition being mounted in the specified directory with access permissions set to drwxr-xr-x. When performing the same steps with a ntfs drive this results in access permissions set to drwxrwxrwx. The reason is surely that ntfs is mounted as fuse filesystem while exFAT is natively supported by the kernel (for some time past). Because I used ntfs before I was not aware of that difference in behavior and it did not occur in my tests when first time using restic and trying to restore files.
T.l.d.r.: For me the solution was (/would have been) to make sure I have sufficient writing permissions.
I will open up a feature request related to this topic: The reason I did not found the issue myself was that the error messages indicating the real problem where dumped out of my shell by the thousands of lines of consequential error messages. I think that could be improved.
@MichaelEischer Thanks again, your post has shown me the direction to track down the issue! Will you as a moderator maybe mark this post as answer?