Veeam 9 backup modes / parallel backup & restore

[mkretzer]

In the past we used reverse incremental for our backups. Sadly we always had the problem that we could not do restores from a backup when the corrosponding backup was just running.

So we switched to classic incremental backup with weekly synthetics, with this we do not have this issue.

Would per-VM chains help (so that only the specific VM is locked)? Is there any other new feature in V9 which helps with this?

[Shestakov]

Hello,
Indeed during backup activity with some methods like reverse incremental, the files are locked during merges, so you need to finish/stop the job to perform restore.
But I would recommend to keep using incremental method if you need to restore during backups often.
Thanks!

[mkretzer]

Sadly we restore quite often during the week.

So the only thing we could do is transform increments into reverse increments?

[Gostev]

The opposite.

[mkretzer]

I did not understand that. While previous increments are transformed into reverse increments in "Transforming Incremental Backup Chains into Reverse Incremental Backup Chains" mode is the latest full backup locked or can we restore at least from the full?

[foggy]

Transformation into rollbacks is performed along with the synthetic full only, so every other day you will be able to restore from the latest restore point even during the backup (however, not on the synthetic full day).

[mkretzer]

So on synthetic full day at first (while the syntetic is beeing generated) it should be possible to restore the backups from the day before the new synthetic full correct? And then when the reverse incrementals are beeing created we can only restore the newest point from the new synthetic full correct?

[Shestakov]

Reversed Incremental mode doesn`t have Synthetic Full runs.
The point here is to switch to forward incremental with Active fulls if you don`t want backup job to lock your files. If you use forward incremental with Synthetic fulls you will ve able to restore during every backup session besides the synthetic full one.

[foggy]

So on synthetic full day at first (while the syntetic is beeing generated) it should be possible to restore the backups from the day before the new synthetic full correct? And then when the reverse incrementals are beeing created we can only restore the newest point from the new synthetic full correct?

The entire chain (containing involved latest full and corresponding increments) is locked from the point when synthetic activity starts until the end of transform.

[mkretzer]

Why should the previous full be locked for reading while the new synthetic full is created? Can not both processes (SF creation and a restore) access it concurrently?

[foggy]

Chain is locked for write since all the files are going to be modified (transformed into rollbacks), including the previous full.

[mkretzer]

Chain is locked for write since all the files are going to be modified (transformed into rollbacks), including the previous full.

But at the time this transform runs we can use the newest synthetic because that is not changed, correct?

[Shestakov]

What do you call "Newest synthetic"?
Until the job is finished you can`t use the newly created full backup and the previous chain that .vbk is made of.

[mkretzer]

From what i understand it is a two step process with the transform option set. At the beginning there is a full and several forward increments on the disk. Now a new Synthetic Full needs to be created.

Step 1: A new synthetic full is created. While this is running we should be able to restore from all but the newest backups because the process is only reading from the old backups, correct?
Step 2: After the synthetic full has been created the previous forward incrementals get transformed into reverse incrementals. The "old" full cannot be accessed that i understand but the new synthetic full which has already been created should be accessible and restorable should it not?

[foggy]

Transformation works a bit differently, there're actually no two steps in this case. Anyway, the entire chain is locked and you cannot restore from any of the restore points involved in the transformation process.

[Shestakov]

Would per-VM chains help (so that only the specific VM is locked)?

By the way, in a case of per-VM chain, all files are also kept locked until the job is fully done.
Once again, the main suggestion to be "always restorable" is to use forward increments + active fulls.
Thanks!

[mkretzer]

OK i understand. Is there any Plan to introduce a mode in which we get space efficient backup but are still always restorable (at least the latest point)? MS dedup is no Option for us right now because our backups are too big even for Single VMs.

[Shestakov]

I`m not sure if such a mode is in the road map. Do you use backup copy job?
Our best practice includes having 2 copies of backup (3-2-1 rule), so one copy is always restorable.

[mkretzer]

Yes we do to another site but over a high speed Link!! I did not think about this this really helps!

[mkretzer]

The only issue now is: what when veeam Server shuts down in the middle of the backup transform? Will all the restore points be corrupted on the primary site?

[Gostev]

No, your restore points will be fine and power off will never result in data corruption no matter what.

Of course, we designed our engine fully expecting that power off can happen at any moment in time. Our backup storage updates are transactional, so we always know were the "good" data is, and are always able to cleanly rollback (or complete) any failed transform operation upon job retry.

[foggy]

A little but essential addition: your restore points will not be actually corrupted after power off, however, you will not be able to restore from any of the involved points until the entire chain is repaired at the beginning of the next job run.

[mkretzer]

Is it possible to trigger the repair manually?

The szenario is this: if we get a major power outage in the area and something bad happens to the primary SAN it might be necesarry to restore without having the possibility to run another backup after power is back up...