Question for you. With regard to the storage that is used for Veeam Backups... I have a site to site backup running at the moment and i want to optimize the storage. What i would like to know is if i should optimize the storage for Read capability or for Write capability. I would like to know if the software works more intensively with writing to the storage especially if its working on the Transform process or if it reads more intensely on the backup files.
Here is the outline of I/O operations for different backup modes:
Incremental backup = 1x I/O on target (write for each changed block)
Reversed incremental backup = 3x I/O on target (write + read + write for each changed block)
Active (real) full backup = 1x I/O on target (write for each block)
Synthetic full backup for incremental backup mode = 2x I/O on target (read + write for each block)
Synthetic full backup for incremental backup mode with transform = 4x I/O on target (read + write + read + write for each block)
Having this in mind, I can say that synthetic full (with or without transformation) gives the ~50% R/W ratio, while it is about 33%/66% for reverse incremental mode.
However, here you should also keep the I/O randomness in mind. Synthetic full itself is mostly sequential reads and writes, while transformation to rollbacks produces heavy random I/O.
Just a question on Reverse incremntal job (V5 currently, in the process of migrating my jobs to V6 and VSphere 5). I do weekly fulls with between 3-6 reverse incremntals in the week. I understand why fulls using sequential i/o are so quick, but why do reverse incrementals (using change blocks) take a little longer each time they run? Does the amount of i/o increase slightly after each run?
So say my Saturday full takes 15 minutes @ 192mb / sec (176gb machine,using direct SAN... raw transfer from SAN is about 85 meg/sec)
Monday 6.21 mins @ 472mb sec
Tuesday 7.36 mins @ 375mb sec
Wednesday 8.01 mins @ 374mb sec
Thursday 8.35 mins @ 350mb sec
Fridays 8.57 mins @ 325mb sec
Its not a problem, just more curious of the reverse incremental process? If there is an extra impact on i/o with each run, would longer rentention and less frequent fulls effect this?
Does using forward incrmentals not manifest this issue due to less target i/o?
Here is the outline of I/O operations for different backup modes:
Incremental backup = 1x I/O on target (write for each changed block)
Reversed incremental backup = 3x I/O on target (write + read + write for each changed block)
Active (real) full backup = 1x I/O on target (write for each block)
Synthetic full backup for incremental backup mode = 2x I/O on target (read + write for each block)
Synthetic full backup for incremental backup mode with transform = 4x I/O on target (read + write + read + write for each block)
Hi Foggy,
Does this rule still applicable for Veeam Backup v9.0 ?
--
/* Veeam software enthusiast user & supporter ! */
Yes, and you can add forever forward incremental here, which also requires 3x I/O, though only 1 I/O is performed during the backup process (single write) and the rest 2 I/O are done "post-process" during a merge at the end of the job, making the backup itself much faster than with reverse incremental.
Cool, so I guess I can now convert the existing large file server & SQL Servers VMs Backup Job into forward incremental to get the full benefits of that ?
Do I have to trigger the Active full or it will do it automatically on the scheduled backup window ?
--
/* Veeam software enthusiast user & supporter ! */
Not convert, but just switch. Active full is not required, after editing the job, it will continue creating increments based on your latest restore point, which should be full, provided you're using reverse incremental now.