On Tue, Jun 14, 2022 at 5:25 PM G.W. Haywood via BackupPC-users < backuppc-users@lists.sourceforge.net> wrote:
> Hi there, > > On Tue, 14 Jun 2022, gregrwm wrote: > > ... interrupted BackupPC_dump. on the next invocation i got: > > 2022-06-12 21:35:02 Serious error: last backup > > /var/lib/backuppc/pc/avocado/32 directory doesn't exist!!! Need to > remove > > back to last filled backup > > 2022-06-12 21:35:02 Deleting backup 14 > > 2022-06-12 21:35:08 Deleting backup 15 > > 2022-06-12 21:35:14 Deleting backup 16 > > 2022-06-12 21:35:20 Deleting backup 17 > > 2022-06-12 21:35:27 Deleting backup 18 > > 2022-06-12 21:35:34 Deleting backup 19 > > 2022-06-12 21:35:41 Deleting backup 22 > > 2022-06-12 21:35:47 Deleting backup 30 > > 2022-06-12 21:36:00 Deleting backup 32 > > > > wow. not too robust! doesn't that seem like an inordinate consequence? > > Mr. Kosowsky didn't specifically address the robustness issue so I'll > chime in here about that. No, it doesn't seem inordinate if you think > about how BackupPC manages backups. The non-filled backups are based > on a filled backup. If you don't have that, then backups which are > based on it are useless so there's no point in keeping them. I think > the moral of the story is that if you care about your backups, don't > do what you did (nor anything like it) without taking precautions. > > Having said that I don't generally mess with BackupPC (whether it's in > the middle of doing something or not). After a couple of false starts > (which must have been at least partly my fault, while I was migrating > from V3 to V4) once I got version 4 settled in it has never put a foot > wrong backing up dozens of machines, which aren't even all in the same > country, with tens of terabytes of data. Occasionally I recover files > and directories from the backups; it's often much easier than fetching > them from the backed up machines directly. I've found that doing this > makes me more confident of BackupPC. That then makes it more likely > that when I need to fetch more files I'll grab backups rather than go > to the originals. It gives me a warm fuzzy feeling I suppose, to know > the recovered backed up data is exactly what I expect it to be, so I'm > that much more confident that if I needed it because I've managed to > lose the original then it would be there for me. > > I have no axe to grind. I'm not in any way connected with BackupPC > development nor with the developers, I'm just a very satisfied user > and I thought that a message which could be seen as critical needed > something to balance it. Of course there will be faults to be fixed > in any even moderately complex software. BackupPC is probably a bit > more than just moderately complex, but I've found it very robust if > treated with reasonable care. > we've been using backuppc3 many years now, it's still chugging along and i'm just getting backuppc4 going. yes i'm quite happy with it and find it robust. but hence my surprise that an interrupt can have this consequence in backuppc4. the 'robust' merit is called on the carpet if a power loss can result in significant loss of backups. offhand i'm not really seeing why an interrupt would result in the loss of a prior backup directory. i'd be surprised to learn that a prior backup is ever moved or renamed and thus subject to loss if interrupted, but what else could it be? if an existing backup directory is ever renamed or moved i would consider that a design flaw worth correcting. i would think it preferable that once a backup directory gets it's number, it keeps it for it's entire lifetime, no renames, no moves.
_______________________________________________ BackupPC-users mailing list BackupPC-users@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
