The need for Active Full backups

[foggy]

Hi Ian, just to add regarding compact operation, since this topic doesn't answer this question - it is available for forever forward incremental or reverse incremental backup methods only, since they maintain a single full backup that might become fragmented with time. It is not relevant to simple forward incremental method though, where new full is periodically created. Thanks.

[Gostev]

Since this topic spans 4 years now but still gets referred to, I wanted to share the current status and finally lock it down.

As of 2019, over 75% of Veeam's 300K+ customers use some form of forever incremental backup mode, making it trusted and proven technology to rely on.

Generally speaking, there are no practical reasons left for doing periodic active fulls, because all of those reasons why customers did them back in the days have long been addressed with the corresponding functionality for incremental forever chains in the product itself: storage-level corruption guard, full backup defragmentation and compaction, and backup recoverability testing (SureBackup).

Some customers still like to do active fulls based on internal policies and regulations, or simply because it makes them feel more comfortable. We don't mind this practice, however we also want to remind that this did not help users with a couple of major data corruption bugs that platform vendors experienced in the past years. Thus, even if you use periodic active full backups, please don't treat them as a substitute for features mentioned above.

The only valid use case that does remains is backup storage specific: some deduplicating storage or low end NAS can be simply too slow (from IOPS perpective) for synthetic fulls processing. For NAS which support iSCSI however, this can be addressed by using ReFS via iSCSI mounted NAS LUN.

[Shunx239]

Well, I think the claim of Gostev is somewhat optimistic.

The truth is the other scenarios than Forever Forward Incremental are badly supported by Veaam.

For a long time I had been a fun of Forever Forward Incremental. However from time to time we needed an active full to be run, thus extra space in the backup repository had to be provisioned.

Since we need periodic full to be saved on the tape we were more happy to save active full rather than virtual one.

The pitfall is as soon as you schedule an active full as an option of backup plan (rather than launching it externally fom the PS), Veeam considers the backup chain to be of different type: Forward Incremental and stops merging older restore points beyond the retention limit.

Actually with daily backup, monthly active full enabled and retention of 8 restore points to keep, we arrive to have 38 restore points on the disk (30 of old chain and 8 of new one).

Sometimes I feel that people at Veeam have their own very special idea about how their software should be used and provide no room for customer to build his own backup flow.

Enabling oldest restore point merge in Forward Incremental would be desired in the described scenario, may be less useful with weekly full and 30 restore points to keep.

I am rather sure some advanced technique is available with Backup Copy, we use tape instead and it is known to be a stepchild in B&R.

Just my $0.02
Nikolay

[PTide]

Hi,

<...> we were more happy to save active full rather than virtual one.

May I ask you why so? Are there any limitations for you in the way how virtual full to tape functionality works?

Thanks!

[csydas]

For a long time I had been a fun of Forever Forward Incremental. However from time to time we needed an active full to be run, thus extra space in the backup repository had to be provisioned.

Since we need periodic full to be saved on the tape we were more happy to save active full rather than virtual one.

The pitfall is as soon as you schedule an active full as an option of backup plan (rather than launching it externally fom the PS), Veeam considers the backup chain to be of different type: Forward Incremental and stops merging older restore points beyond the retention limit.

Out of curiosity, why not do the Virtual Fulls? Even on our lower end storages they're still not too bad, but we just commission older production servers to be repositories, so I guess we have the IOPs.

Alternative, what about doing a periodic backup export? That feature has helped out a colleague of mind working on a really weak inherited infrastructure; he just exported at his leisure which day he wanted and managed those fulls with File to Tape backups. Would that work in your scenario?

[Shunx239]

Thank you Csydas and P.Tide,

Indeed the poor D2T performance of Virtual Fulls was the main reason why we prefer taking Active Full when possible. We still use Virtual Full for GFS job and can see the difference for the same data (2,2 TB transferred):

Tape job (Active Full): Duration: 13:57:36 :: Load: Source 87% > Proxy 24% > Network 14% > Target 54%
GFS tape job (Virtual Full): Duration: 27:17:07 :: Load: Source 98% > Proxy 9% > Network 1% > Target 15%

We don't have much IOPS on the repository but the throughput is reasonable. We use iSCSI volumes mounted on backup proxy local to the VMWare host and are happy with this design tuned for backup performance.

For me it is a limitation to be unable taking advantages of backup chain maintenance already implemented in the B&R but hard coded to slightly different flow.

[backupquestions]

Why wouldn't you just switch to REFS file system with 64k block size and then start doing synthetic fulls? (Why are we calling them virtual all of a sudden?? Lol)

The time to complete will be massively faster than you posted.

[csydas]

@Alabaster,

Virtual Synthetic Full refers to the Tape process of making a Full Backup to tape from an Incremental point. Nikolay's point was that he needed an easy path for D2D2T and the VF process is too I/O intensive for his storage.