VBR + VAW - Backup with Periodic Full's

[Fledge]

Using VBR integration with controlled VAW Server agents

In traditional VBR if you have a forward backup job and set it to have periodic full backups, I think you have the option of converting the forward incrementals preceding a new full into reverse incrementals. Thus you can maintain a sliding retention period window, have the full in the chain periodically refreshed and only have one full in the chain

This is not an option when using a a VBR integrated/controlled VAW agent ? - VAW backups have to be forward forever incremental even if VBR is in the picture ?
i.e. in this scenario there is no option to convert the forward incrementals preceding a new full into reverse incrementals, all you can have is two fulls (the original plus a new periodic) with their own forward incrementals until they age out through the retention period

With large backups and paid storage am trying to achieve the following

• Say a 14 day retention period (with multiple backups per day)

• Say every fortnight, have a new full (but retain the running 14 day restore point window)

• Only have one full at any one time

With VBR + VAW this is difficult/not possible ?
BCJ to another host might be a way out ?

Any suggestions

Thanks in advance

[Dima P.]

Hi Fledge.

This is not an option when using a a VBR integrated/controlled VAW agent ? - VAW backups have to be forward forever incremental even if VBR is in the picture ?

Veeam Agent for Windows does not support reverse incremental backup.

i.e. in this scenario there is no option to convert the forward incrementals preceding a new full into reverse incrementals, all you can have is two fulls (the original plus a new periodic) with their own forward incrementals until they age out through the retention period

Maybe just use synthetic full backup instead? Full backup is going to be created on a desired day from the existing incremental restore point while the rest on the incremental restore point will remain untouched and will be removed according to the retention.

BCJ to another host might be a way out ?

Backup copy job support backups files made by agents but it's running in forever incremental backup mode. Cheers!

[Fledge]

Hi Dmitry, thanks for the quick reply

The reason I was looking at periodic fulls was to try and ensure the health of the backup chain. Have had a problem with VAW forever forward chain that had run for a while, it did not completely fail/loose data but the full restore time ballooned, the effective restore data rate dropping greatly in throughput. Kind of makes you uneasy about relying on a forward forever backup chain that been running for some time

Some further background

Haven't got Enterprise - so no Surebackup

The periodic 'check health of backup' function would take too long to run
(the full backup size is ~ 4TB, there 3 backups a day and the incrementals can be a few 100GB each, with a 14 day retention period)

The periodic 'defrag full backup' function looks like it needs backup size disk space for its temp file

Hence why was looking at doing periodic full to ensure freshness but couldn't immediately see a way of achieving that, within the criteria i'm aiming for

Of course I can restart the job and get a fresh full but loose the established 14 day restore points (why was thinking of CBJ to another host to try and retain, and would probably have to perform some manual process to achieve)

Or do a periodic full but that cost at least 2 x full backup in $ per GB storage space

Sorry - should have added that the backup I had the slow throughput restore experience with was a BCJ backup on a remote VBR repository, the BCJ ran across a WAN, the source for the BCJ being a VEB agent backup on a local VBR repository

Cheers !

[Dima P.]

Haven't got Enterprise - so no Surebackup

Won't help anyway as SureBackup job does not support backup files made by agents.

The periodic 'check health of backup' function would take too long to run

Can you please clarify how much time was spent on health check?

Or do a periodic full but that cost at least 2 x full backup in $ per GB storage space

That's true, with periodic full backup you have to store more restore points based on retention logic.

slow throughput restore experience with was a BCJ backup on a remote VBR repository, the BCJ ran across a WAN, the source for the BCJ being a VEB agent backup on a local VBR repository

Was that a first job run or you constantly see slow performance even when incremental restore points are transferred? Thanks!

[Fledge]

Think when tried before health check took over 10 hours but to be fair we prob need to test it again

The slow restore was seen when using the BCJ chain for a migration. The agent backup (with ~ 42 restore points) and the BCJ (which had the minimum chain of 2 restore points) had been running for say six to nine months. Had done this in DR testing on previous occasions and it seemed ok, it just chose the migration to play up on !

Happy Old Year

[Dima P.]

Hi Fledge,

health check took over 10 hours but to be fair we prob need to test it again

Once you have new results please do not forget to share them with us.

slow restore was seen when using the BCJ chain for a migration

Thanks! Restore does not use WAN accelerator cache (data retrieval goes in different direction, so there is no way to utilize cache). I'd recommend to keep the local backup for fast recovery and use backup file produced by backup copy only when you primary cope is lost.

Happy New Year!

[Fledge]

Have run a couple of health checks on our main VAW chain (~9TB native data source = 4TB full + 41 incremental's = <5TB )

Health check takes ~ 12 hours to complete