I’m using an OLD restic version (0.3.3), and now it is time to upgrade (finally).
Reading I learnt we cannot mix too old binaries and new one, due to a change in the repository, but I would change from the old to the new and never look back (if it works of course).
I also know that using restic copy from a repository to another one is not perfect because the new and the old snapshots are not deduped correctly.
Restic is a statically linked binary.
This leads me to 3 questions which I’m afraid I wasn’t able to locate in the docs nor in the forum.
Can I create a new repository with the latest restic version and copy from the old to the new? The new would be empty, so I expect a perfect deduplication of the old data. Since I’m not using the old repo I think I should not use restic migrate. Is all of this right?
Can I simply use the new binary on an old debian stretch or there are some dependency issues? Now I’m using the shipped version 0.3.3 which is really old. (Now even debian strech is obsolete, so any software version shipped in it is really ancient).
Is my migration approach (new binary, init, copy) the best in my case or are there some better paths? My first goal is ensure a secure migration without data loss, time and effort is not an issue.
Thanks for your help and for restic: after two years I’ve recently had to restore a lot of data due to a filesystem corruption and it saved the day (ehm about two weeks, due to the restore size, but still )
Hm, I think that’s not correct: you should be able to read (and write) your old repo with the most recent version of restic.
We’ve recently (in the Git master branch, not released yet) added code for a new repository version, but that’s strictly opt in, older repos will just be read and written just as usual.
You can work around that by initializing the new repo with the old chunke/deduplication settings (via restic init --copy-chunker-params.
Likely you can do that. It may happen that your kernel is too old for the version of the Go compiler and runtime we used to build the binary though, but it’s not dependent on any library that comes with Debian.
That’s the safest way for sure, but you don’t really need it unless you want to try the new compression code. Otherwise just use a new restic version and keep using your old repo.
I’ve executed a restic check vith a 0.11.0 binary and it is not good: there are some errors. I’l try to figure out what to do, but I think I’ll open another topic: there are some confusing errors like “pack in multiple indexes”, “pack not referenced by an index”, “id xxx not found”, “tree not found”, “file not found”… It seems I’ve got all the possible damages check looks for
)