I have this idea about how I might be able to preserve some of my backup archive from CrashPlan when changing to Duplicacy and I wonder what the pitfalls might be or if there is a better strategy.
So, to start with, I think I can live with losing the the different versions/revisions of my backed up files that I can currently still access in CrashPlan. My main aim in this whole exercise is to copy over the latest version of all files I ever backed up, including (and in particular) the ones that have in the meantime been deleted (I have CrashPlan set to keep at least one version of every file, no matter what). Simply because chances are that at least one of them has been deleted by mistake. Maybe recently, or maybe two years ago.
Anyway, the basic idea is that I restore the latest version of all files in my CrashPlan archive into a separate folder (not to the original location) and then I’ll simply back up that folder.
First I thought I’d create a separate repository for that folder, but then I figured that is not necessary (or perhaps even disadvantageous). I’ll just include the folder in my existing repository and delete it once it has been backed up.
I’ll probably tag that snapshot sith “crashplan” or something so that I know where to find those crashplan files, should I ever need them.
Now here is a crucial question: how do I make sure that that snapshot never gets deleted (since it’s the only one with those (deleted) crashplan files)? Is there any way to mark a snapshot as “untouchable”, i.e. to tell the prune
command to simply leave it alone? The only thing I can find is the -ignore
option but I don’t quite understand what it does. The wiki says:
It also provide an -ignore option that can be used to skip certain repositories when deciding the deletion criteria
.
Does that mean that theignore
option makes the snapshot immune against deletion or the opposite? There also seems to be a confusion with the term “repository” and “snapshot”. The above quote talks about repositories while the official help text talks about snapshots
-ignore <id> [+] ignore the specified snapshot id when deciding if fossils can be deleted
And then there seems to be a nuanced distinction between “snapshot” and “snapshot id” that adds to the confusion:
For fossils collected in the fossil collection step to be eligible for safe deletion in the fossil deletion step, at least one new snapshot from each snapshot id must be created between two runs of the prune command.
Anyway, if it is possible to be off topic in the topic-defining post, then this was off-topic. So back to the real stuff: how to prevent a specific snapshot from deletion? If it’s not possible, here are some specs for a feature request:
- In order to prevent deletion, one should not have to specify the protected snapshot everytime the
prune
command is run. For obvious reasons. - This means that the information about protected snapshots needs to be stored in the backend.
- One option would be to write it to the
config
file - But the easier option is probably to hardcode a specific tag (e.g.
protected
) as marking an undeletable snapshot. Done. It’s a bit less flexible and users are forced to use that specific tag, but its so much easier to implement (and simpler to use)…