free space check

[MAA]

Hello,

Why B&R8 does not check the free space BEFORE creating the synthetic backup?

Now, i have failed job: "Synthetic full backup creation failed Error: There is not enough space on the disk. Failed to write data to the file"

[Vitaliy S.]

Hello,

Veeam cannot know in advance how much space a new backup will occupy, however "reserving" space similar to a previous full might make sense in some situations.

Did you have any notifications (via job session details) in the previous job run saying that target storage is low on free space? Do you have any monitoring tools for your Veeam B&R infrastructure?

Thank you!

[MAA]

Veeam cannot know in advance how much space a new backup will occupy

its not a new backup, its synthetic backup of the files that are already on the disk.
this is your program and you should know how it works in creating the synthetic backup.
now B&R does not do any checking free space before creating the synthetic backup.

[Vitaliy S.]

Yes, I see your point. In order to monitor free space on the repository, you can either use notifications in the job session or tools like Veeam ONE. Thanks for your feedback regarding making checks before creating synthetic fulls.

[veremin]

On a side note, since you're on 8 already and concerned with disk space, is there any reason to use forward incremental mode with synthetic full, instead of new forward forever incremental mode that is more space conservative and doesn't require regular full backups? Thanks.

[MAA]

In your opinion, "Merge" operation is much faster than the operation of the synthetic full backup?

[foggy]

It requires the same amount of I/O, however is performed daily (to inject just the daily changes) instead of building an entirely new full from all the increments created during the week (and hence, does not require space for additional full).

[MAA]

Do you have any recommendations for the type of RAID array (R10/R5/etc) for backup repository?
Do you have any bench results (time) for "Merge" operations of big-sized backups (>1TB) on different RAID types? (especially while simultaneously performing multiple Merge operations)

[veremin]

R10 is always preferable as it has less penalties in comprarison with r5 or r6. Thanks.

[MAA]

R10 have 50% penalty in write operations.

I would like to look at the real-life Merge time results..

[dellock6]

Except Raid0 (which has no redundancy) any RAID configuration have write penalty because a single bit write requires in reality multiple writes on the actual storage. R10 still has the least amount of write penalty at 2, all other modes have higher penalty, especially those with parity (5 or 6 usually).
For write operations like backup activities, R10 is still the best, if you can afford the increased amount of "wasted" disk space.

By the way, you can compare raid configurations and write penalties on this site: http://wintelguy.com/raidperf.pl