Feature request - ability to update imported backups

[arthurp]

Feature request:
1. Ability to update imported backups with further incrementals in the same backup chain.
2. Ability to update restored virtual machines with subsequent incrementals in updated imported backup.

Environment:
Our domain has 3 virtual hosts with fair amount of local storage and small SAN (IBM DS3300). We run VMware + Veeam Essentials package as it meets most of our needs. We use local storage for near continuous replication and in most cases we achieved RPO less than 1 hour (SQL server excepted as client applications don’t handle well snapshot removal freeze). All is well on replication front and we mostly use replica failover feature to move virtual machines around when servicing or upgrading hosts.

Our next step was to establish an offsite DR environment. We use VBR to backup virtual machines to NAS nightly (forward incrementals with weekend synthetic full) and copy these files to removable eSATA drives. DR environment has a decent desktop with VBR and a standalone vClient. Veeam backups from removable drives are imported to VBR in DR environment and subsequently restored to virtual hosts. Full environment (8 virtual machines with approximately 1TB data) has been restored from scratch in 12 hours which we consider acceptable at this point.

Our design is not perfect, but allows us to bypass WAN data transfer as it is not possible at our location. Also, eSATA drives are cheap and quite fast.

Now, what can be done to reduce recovery time? Please, consider the following scenario.
1. Initial DR setup is performed as described above, tested and turned off at DR site.
2. Main site VM backup is changed to forward incremental only (no active or synthetic full backups).
3. These incremental backups will be copied to removable media and used to UPDATE already imported backups in DR site VBR.
4. New incremental data will be used by VBR to UPDATE already restored virtual machines periodically.

This will produce 2 main benefits:
- original DR setup will be already verified and tested
- amount of data subject to copy and restore will be significantly reduced along with recovery time

Please, feel free to comment, critique, etc. Does anyone else think that these features will add value to this otherwise already very good product?

[Gostev]

Hi Arthur, basically (2) is impossible, you have to have periodic fulls with regular incremental backup. If you are trying to achieve forever-incremental over WAN, you can do it today when backing up to a Linux target located in DR site, have you considered that? In v6, we are adding the same capability with Windows targets.

[arthurp]

Hi Anton,

Unfortunately, WAN replication is not an option at this time at our location (hopefully in future we will use it). What I had in mind for feature 2 is something similar to SQL restore process when you restore the database and leave it in restoring state that allows you to restore additional logs. Unlike WAN replication that requires systems running at DR site, this approach would allow to use "cold" site for DR and power it up only for scheduled restores from disk and testing. I understand that this feature is not anywhere on the map. It will, however, allow to setup DR once, save time on repeated full restores and significantly lower RTO.

Thank you

Arthur

[Gostev]

OK, got it. So you can transfer increments strictly on removable media. With total VM size of just 1TB (and even smaller backup file), have you though of using reversed incremental backup job and just copying latest VBK every time you need to get the data over to the DR site?

[arthurp]

Originally we used reverse incremental and it is still possible. In fact, we still do synthetic fulls on weekends. On the other hand, using forward incremental allows to speed up backup jobs and offload the task to rebuild entire VM to DR environment. For comparison, our file server full backup is appr. 200GB while typical vib will be under 4GB. It will save time twice: copying to removable media and full VM restore in DR. Even on fast eSATA there is significant time difference. It will be even more useful for larger environments.

Another great benefit of this approach could be that DR environment can be set up and tested once and only updated on continuous basis later. This could further reduce any uncertainty the clients might have, especially with AD, Exchange and DB servers. I understand that it is easier said than done, but again it might be a good feature addition.

[Gostev]

This feature has certainly been on our radar for a while, I've just been lazy to look up existing discussion to merge this topic there.
Above, I am just trying to give you some immediate workarounds that you can use today, until this is implemented. Thanks!

[arthurp]

No problem. Good to know that you might be implementing it in future. Thanks for your input.