Included cleanup of partial failed backup

[MalakymR]

If a backup fails, the rotation script will delete a previous good backup without a new good backup.

This cleans up the backup, though does not handle the creation of the STATUS.error file - shouldn't this be left to the logs? I don't know how else this can be handled.

The alternative would be to not rotate on error, but if you start with 2 good, 1 bad with rotate of 2. You now have 2 good 1 bad and then on the 4th backup which is good (2 good 1 bad 1 good) the rotation would cull 2 good leaving 1 bad 1 good which still isn't ideal.

#107

[awalon]

Much simpler as my modification (nice). But if the failed backup was be removed multiple days there's no recent backup (maybe some of the disks are availabe). Detected the problems days later without any backup.
Additional rotate for failed backups should be added to save store on backup system.

#86, Diff

[MalakymR]

I had thought of that, but dismissed it due to making the rotation checking slightly more complicated, and dependant on the STATUS.ok/error

I'm not even sure I like the STATUS files, better it goes into your logs/notify etc.

Leaving a partial backup could cause a knock on effect which cause more to fail which may be fine otherwise. Considering you need all the space free for the next backup, then you may have multiple running close to each other (hard to know how long some of these will take) you will be left with more failures. If it fails it only removes the partial VMDK, but if your VMs have multiple the completed full ones stay.

There are many ways this could be handled - someone just needs to decide.

A size estimate before starting would be nice come to think of it.

[awalon]

I like the Idea with the size check. if possible keep partials (failed) and remove them on next turn (before backup starts). If we need the space (dynamic rotate of failed files before backup) the fails will be removed. Will have a look on this next days (looks as a good solution for my szenario).

[MalakymR]

Size isn't all straight forward though - since the output can be well under what you expect, and compressed filesystems will give you more on top of that too.

Checking my storage vol, which has just backups, its at x2.17.

What reasons would anyone want to keep a partial backup? I guess its better than nothing (backup of disk1, but missing 2 better than none), but what happens after that is also an issue (stuck with 3 backups that only have disk1 for instance).

[awalon]

Yes the compession is not easy (at least not exactly) to handle. My motivation about the partial backups is as simple as "better than nothing". Of course the more important feature is an alert/monitoring (operator intervention needed). But in my situation (cannot check and/or solve the problem on same or next day) the relevant disks can be combined out of the "most recent" version of the backups if needed (or a single "very important" file).