Feature Request: Transform later

[wfturner_merit]

After working on another problem with a helpful tech, we came up with an interesting idea regarding Synthetic Fulls and Transforms. At least in our case, it would be extremely beneficial if we could schedule one or both of those operations for a period of time after the backup window.

As you know, the Transform operation can cause heavy IOP usage on your storage platform, reducing the performance of any backup jobs currently running. As our backup window ends at 8 AM (4 AM hard cutoff to account for cleanup), we would prefer to run the Transforms/Synthetic Full creation at that time, when the backup storage is unused.

Anyone else think this would be a good enhancement?

[tsightler]

One challenge with this approach is that your backup files would then be locked during the window when you are likely to need to perform restores.

[jjblaster]

That is exactly what I am looking for right now a Veeam transform tool that I could schedule or manually run as needed. My storage is limited and this would definately be a great addition to Veeam. Is there any tools that can used at this time to manually transform the synthetic backups?

[Gostev]

No tools like that. When would you schedule the transform if you had such an option?

[wfturner_merit]

As a service provider, we would prefer the option to delay the transforms until the day. Our backup window for certain customers is very limited, as customers get to set it. We want the backups to perform as fast as possible during the window, then run the transforms during the day when our backup storage is idle.

Currently, using forward-incremental backup, this kind of works, as a transform operation will finish even if the job hits the "end of window" timeout. The transforms still do generate a fail amount of IOPs on our (slow) backup storage, which makes most of the other jobs run slower. Right now we're within tolerance, but having more options is always better in our eyes.

[dellock6]

Working too for a service provider, I found out at the end it's all about the target storage. We scaled out proxies, repositories, configured many different options like doing a setup of a race car, by small changes and "fine tuning", but in the end the target storage is the potential "show stopper" of it all.

As Tom correctly said before, postponed transform is a non option for us, right because we would not be able to do a restore in the middle of a transform. To reduce the backup window (whn the budget will allow it of course) our next step will be to increase the size of the deduplication storage and slowly move all the backups from the actual "plain" storage to it. Backup will be reduced in time by lowering compression and deduplication made by Veeam, and get savings on space anyway thanks to the dedup appliances.
Hopefully, this will give us both backup speed/short backup window, and savings on disks.

Btw, a key difference in a service provider environment is the retention time, ours is by default 7 days as long as a customer does not asks for more, while at many customers I go to they usually need longer retentions periods.

Uhm, maybe this is an incipit for a new blog post

Luca.