![]() Jan 1 06:09:23 Server-1 kernel: md: recovery thread: PQ corrected, sector=1962934200 Jan 1 06:09:23 Server-1 kernel: md: recovery thread: PQ corrected, sector=1962934192 ![]() Jan 1 06:09:23 Server-1 kernel: md: recovery thread: PQ corrected, sector=1962934184 Jan 1 06:09:23 Server-1 kernel: md: recovery thread: PQ corrected, sector=1962934176 Jan 1 06:09:23 Server-1 kernel: md: recovery thread: PQ corrected, sector=1962934168 We recently experienced an extended power failure, and I noticed 5 parity errors, on both servers, after the servers were restarted. My two Unraid servers have been running nonstop without any issues for many months, last I looked the uptime on v6.7.2 was around 240 days. ignore PC2_user_docs is equivalent to marking PC2_user_docs as being inactive for 7 days.This post started with a quick experiment, but after hardware incompatibilities forced me to swap SSD drives, and subsequently losing a data volume, it turned into a much bigger effort. Those fossils are unlikely to be referenced by any backup from PC1_user_docs, so they will be permanently removed.Īs you can see, you can avoid this scenario if you never run the prune command and the backup of PC2_user_docs at the same time, or if the the backup of PC2_user_docs finishes before the second prune command (in which case the second prune command will find out that the fossils collected by the first prune command are indeed needed by the latest backup from PC2_user_docs).Īnswering your other questions, -all means that the retention policy applies to all repositories. Because the last backup from PC2_user_docs was more than 7 days ago, it thinks PC2_user_docs is inactive, so it will consider only PC1_user_docs. ![]() The second prune command checks if the fossils collected by the first prune command are referenced by any new backups that appeared after the first prune command ends.Since the backup of PC2_user_docs hasn't finished yet, there isn't a new backup from PC2_user_docs. It loads the fossil collection saved by the first prune command and checks if there are any new backups that the first prune command didn't see. But the backup of PC2_user_docs continues to run. The first prune command saves the fossil collection and exits.The first prune command starts to collect chunks it deems unreferenced and marks them as fossils some of these chunks may be referenced by the ongoing backup of PC2_user_docs but the prune command doesn't know.The first prune command starts while there is a backup of PC2_user_docs that is still in progress.This is because the only scenario where a chunk owned by a backup of PC2_user_docs can be deleted by a prune command is as follows: If you can't enforce that, then just make sure that the backup of PC2_user_docs takes a shorter time than the interval between two consecutive prune commands. If you can make sure that the prune command never runs simultaneously with the backup of PC2_user_docs, then you should be fine. duplicacy prune -ignore PC2_user_docs (is this the same as the default behavior after 7 days?).This sounds like a good idea if I wanted to prune stale or deprecated repos manually. It also provide an -ignore option that can be used to skip certain repositories when deciding the deletion criteria. duplicacy prune -all (is PC2_user_docs still auto-ignored after 7 days?).Duplicacy by default will ignore repositories that have no new backup in the past 7 days.ĭoes this mean I should never prune twice between all repositories backing up? Can I get prune to not ignore stale repositories (and is this what the -all option does)? However, some repository may not be set up to back up with a regular schedule, and thus literally blocking other repositories from deleting any fossils. Realistically this would be unlikely, but I am trying to understand the exact behavior).ĭescribed here at the very bottom of the prune command:į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. (If I deleted shared data from one repo but meant to keep it on the other. I'm concerned the infrequent PC2_user_docs backup could have chunks lost during pruning. PC2_user_docs to b2://mybucket (every 10-ish days)įor the sake of this example let's say I'm pruning frequently with some sensible -keep options.Let's say I have 2 repositories backing up infrequently to the same location: I'm still learning and don't have a test repo old enough to try yet. I'm a little confused on the usage/explanation of some prune options, I hope this is the right place to ask.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |