• Any environment variables relevant to those commands (including their values, of course).
none
• The complete output of those commands (except any repeated output when obvious it’s not needed for debugging).
I don’t need to debug, I have a question about repository management and no failed commands.
I have used restic to backup my data to a RAID array of two flash drives. That worked well until I ran out of storage and did not want to get rid of backups. I now have a new flash drive of ~256GB. I keep multiple copies of my restic repository copied/synced with rclone. Now that my ~128GB RAID array is full I would like to “fork” an existing copy of that repository into a new independent repo, where I can forget and prune my oldest snapshots and only keep most current ones. Is this possible currently without a full rewrite?
I don’t quite understand what you mean by “fork” if I’m honest.
You could copy the repository files (using rclone, cp, rsync, etc.), then you’d have a duplicate of your repository in a second location.
You could also init a new repository in a second location using --copy-chunker-params, and then run restic copy to copy the snapshots from source to target.
Both approaches give you a repository that is a duplicate of the original, yet can be used completely independently, assuming you don’t repeat the initial copy operation.
By this do you mean “can I copy only some snapshots?” to which the answer is yes, you can pass a list of snapshot IDs to copy to restic copy, and it’ll only copy those snapshots into the second repository.
The only problem I can see is that since the repository is clone with rclone, so is its repository ID, and that may cause problems with cache. Restic thinks both copies of the repository are the same repository when one copy have all snapshots and other copy have only a subset (after forget and prune).
I have not tested copy from repository ID “X” to another different repository that has ID of “X” too so I do not know how restic behaves in such case.
Also this is the only problem I can see, there may (or may not) be others.
I just tested the repo ID duplication with a small test setup and it indeed does work fine (so far). I just want to be careful not to instantly break my backup sets.
Restics cache is designed to be ephemeral, so it shouldn’t cause any problems I don’t think. That seems to have been borne out by your testing so far.
To clarify, the copy approach gives you a completely different repository - you init a new repository first before copying the snapshots from the old repository across. The only thing in common between the two repositories would be the chunker parameters. See the relevant section of the docs for details: Working with repositories — restic 0.19.1 documentation
I would do that new repository init route if I were to start from the scratch, but given I already have my old storage media with currently all backups I prefer to not recreate it. since chunker parameters are part of a repository I know I have them the same way for both copies of the repository. Since this now seems to work, I will be using it on my main backup sets.
I marked your first post as a solution, because it’s the most helpful for others I think.
