4 ms·

> work similarly and take similar times Except that I tested them and they didn't. I hadn't "lost locally cached metadata". And it didn't just scan all the sou

> work similarly and take similar times Except that I tested them and they didn't. I hadn't "lost locally cached metadata". And it didn't just scan all the source files again, it re-transferred them over the network. All 4TB of it! That's why it took so long. (At that time the sever was still local, because I wanted to make the initial run not over the Internet. So there wasn't even added latency.) I'm sure it was a bug, maybe even in combination with OpenBSD, which moste likely is fixed now. As I said it was years ago. I compared and was more happy with borg. Which stood the test of time and saved my ass multiple times.

bttger 4y ago
This probably wasn't a bug. I experienced the same last week but it was because I ran the backup command from a different directory. I've created a note saying: `restic backup -v -r <location>/<repo_name> <source_dir>` first `cd` to the parent directory of the `source_dir` to avoid too many nested directories in the repository and conflicts in the mounting point path (so that the file change detection of restic works when mounting the drive to be backed up at another point)