CRASHPLAN LATEST VERSION HOW TO
CRASHPLAN LATEST VERSION ARCHIVE

The recycle bin is something of a special folder. If an existing snapshot isn’t included in the snapshots to be deleted, all chunks that it references are guaranteed to remain in the storage. Which means after seven days the Crashplan snapshot will be ignored and unless that ignoring is a different kind of ignoring than the one triggered by the -ignore option, which, I understood, means that that snapshot risks losing some of its chunks.īut at the same time, you confirmed above that No wait, the seven day period will eventually apply:ĭuplicacy by default will ignore repositories that have no new backup in the past 7 days. In this scenario, there is, by definition, always going to be an inactive repository, which means no fossils will ever be deleted.

CRASHPLAN LATEST VERSION ARCHIVE

the OP), because Nelvin’s ingenious solution won’t really work, unless I am fine with fossils piling up in my story for ever:įirst do a full backup with it’s own snapshot, then create a new, active one, do the full backup again (which should not waste any storage due to deduplication) and then use that one as your active archive Okay, so basically, you only want to use the -ignore option if you have such an inactive repository and you don’t mind the backups from that repo to be be potentially destroyed, right?īut that also means that we’re basically back to square zero (i.e. 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)… protected) as marking an undeletable snapshot.

But the easier option is probably to hardcode a specific tag (e.g.

One option would be to write it to the config file.

This means that the information about protected snapshots needs to be stored in the backend.

In order to prevent deletion, one should not have to specify the protected snapshot everytime the prune command is run.

CRASHPLAN LATEST VERSION HOW TO

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: The above quote talks about repositories while the official help text talks about snapshots -ignore ignore the specified snapshot id when deciding if fossils can be deletedĪnd then there seems to be a nuanced distinction between “snapshot” and “snapshot id” that adds to the confusion:įor 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.Īnyway, if it is possible to be off topic in the topic-defining post, then this was off-topic. It also provide an -ignore option that can be used to skip certain repositories when deciding the deletion criteriaĭoes that mean that the ignore option makes the snapshot immune against deletion or the opposite? There also seems to be a confusion with the term “repository” and “snapshot”. 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. 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. 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. I’ll just include the folder in my existing repository and delete it once it has been backed up. Maybe recently, or maybe two years ago.Īnyway, 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.įirst I thought I’d create a separate repository for that folder, but then I figured that is not necessary (or perhaps even disadvantageous). Simply because chances are that at least one of them has been deleted by mistake. 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). 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. 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.

Crashplan latest version