What if an incremental file gets corrupted with FFI backup?

[Magion]

I'm thinking of changing our current backup configuration to a forever forward incremental backup, with ~30 restore points.

Now, what would happen if an incremental file would get corrupted or missing? Say the 15th? Would that mean that all backups after that point are unusable?
And what about the backups made after that?

[DGrinev]

Hi Magion,

In that case, the 15th restore point and all subsequent will be unusable for the restoration.
That's why performing health checks for the FFI backup chains is highly recommended.

Thanks!

[Shestakov]

Alternatively or additionaly you can use Surebackup verification.

[Magion]

That would've been my next question: how to prevent/repair the backup in case of problems. If I would enable the health check, would that be enough to fix a missing incremental in the backup chain?


Let me explain my setup in short: I currently have a pretty old fashioned backup setup, with daily incrementals, weekly active fulls and seperate backup jobs for monthly and year backups. The daily incrementals with active full backups have 14 days of restore points.
The problem is that this configuration is filling up available storage fast, and the offsite backup (using a different product) is taking to long to finish.

I calculated that is if I would change the configuration to a FFI with 30 restore points I would need almost 50% less storage for the daily backups (while increasing the restore points to 30) and with the smaller backup size, the offsite backup would take less time to finish.

But longer continuous periods of incrementals would increase the risk of more days of backup lost...

[Shestakov]

You will not be able to repair a corrupted backup file, which is the reason why best practice is to maintain at least one copy of your backups.

[Magion]

...and with the smaller backup size, the offsite backup would take less time to finish.

Scratch that. Since the full backup will change every day due to the merging of the oldest incremental, the offsite backup will have to copy the whole full backup every day. Suddenly FFI doesn't sound all that interesting anymore

You will not be able to repair a corrupted backup file, which is the reason why best practice is to maintain at least one copy of your backups.

We have an offsite copy, so we got that covered

I'm still not sure about using calculated backups (FFI, synthetic fulls) though. A periodic active full restarts the backup chain so any corruption during earlier backups would have no effect. (Or maybe thats just the old-fashoined sysadmin in me? )

[foggy]

Scratch that. Since the full backup will change every day due to the merging of the oldest incremental, the offsite backup will have to copy the whole full backup every day. Suddenly FFI doesn't sound all that interesting anymore

Switch to using Veeam B&R backup copy for offsite backups and you will eliminate that.

I'm still not sure about using calculated backups (FFI, synthetic fulls) though. A periodic active full restarts the backup chain so any corruption during earlier backups would have no effect. (Or maybe thats just the old-fashoined sysadmin in me? )

Your understanding of active vs. synthetic fulls is correct here.

[DGrinev]

You can check the best practices guide, section about the Backup Methods, it might help you to make a decision which method to choose. Thanks!

[Magion]

Switch to using Veeam B&R backup copy for offsite backups and you will eliminate that.

But a Backup Copy still has to update the full backup file on the remote storage right? So how does that work, how would this eleminate the copy overhead of a full backup?

[veremin]

After initial transfer backup copy job will copy only changes it discovers. So, it will be true forward forever incremental type of activity. Thanks!