Initial offloading to object storage

[kwinsor]

Hi All,

We have a brand new Zadara object storage platform in eastern Canada. I have two sites across the country with a SOBR per site to enable offload copy as soon as backups are created. Most of our backups are forever incremental with 30 day retention. Some do weekly synthetic full but not many. I have 10 GB connectivity end to end.

I turned on offloading and selected latest for one site but ran into major issues with Zadara performance and the offloading was locking the vbk's and preventing merging of vib's on subsequent backup jobs. I hard stopped it all. Zadara upgraded the IO Engine for us and now i have a clean object instance again. So now I am back to turning this on for the first time again.

Veeam ONE is reporting the following data usage on my SOBR's:
SOBR 1 - 80 TB's of full backups, 33 TB of Increments
SOBR 2 - 46 TB's of full backups, 33 TB of increments

How can I get all of this data into Zadara and not impact scheduled backups? Should I enable an offload window outside of our backup schedules? Will object storage offload tasks terminate properly when the offload window allow closes? This is going to take days if not weeks to catch up.

Looking for Veeam best practice/suggestions.

Thanks.

[Gostev]

Hello!

Actually, offload to object storage is a completely separate process from your scheduled primary backups... so those should never be affected. Offload is also the lowest priority process, so you don't have to schedule it outside of your backup window. Offload process will never get backup infrastructure resources assigned to it regardless, whenever something else is going on that needs need the same resources (backups/restores).

I am a bit puzzled why the offloading was locking VBKs considering the Move policy only processes sealed VBKs, and never the latest chain (the one being transformed)? Do you perhaps copy your backup to object storage, not just offload the oldest ones? If this is the case, give the volume of your existing backups, try starting from only the Move policy enabled to get all those older backups to object storage. If all looks well with performance, enable the Copy mode as well - which will then only need to quickly process the delta in the latest backups.

Thanks!

[kwinsor]

Hi Gostev,

Thank you for your reply. Yes, I enabled the copy mode and selected latest when it prompted that the SOBR already contains backup files. The idea here is that we are going to move away from Backup copy jobs to our aging copy servers and Dell MD storage and leverage only copy to object as soon as backups are created. I still have copy jobs as a secondary target for our backup jobs enabled until we get all of our backups copied to object storage.

As I said, most of our jobs are forever incremental with 30 restore points. Only a few have weekly synthetic full backups. It was my understanding that if I use the Move option only inactive backup chains will move so I did not factor that option into my plan. Are you saying that if I enable move for items older than 14 days for example it will offload files that are part of the forever incremental active chains as well?

Finally, we have proxy and repo roles combined on Dell 730XD servers. One SOBR has 4 of these servers and the other site has 5 in the SOBR. I have configured each of the SOBR nodes access to object storage and no gateway node is configured. Is it better to do this over using one SOBR node as the gateway for performance reasons?

I appreciate your feedback on this.

[Gostev]

No, the Move policy process inactive chains only. You can refer to the User Guide for more details, but basically it can only offload files that are no longer to be modified. Think about the Move policy as a backup file archiving. Thus, the Move policy will not do anything to forever incremental chains.

Since using a gateway means data going through a bottleneck, of course it is better when every SOBR node just offloads by itself.

[kwinsor]

Yes the move option functions exactly as I thought it does. So how am I supposed to copy all of this data to object storage with forever incremental backup jobs? If I turn on copy immediately, and subsequent forever incremental jobs run, my console fills with failures because the vbk is locked by the offloading and the latest vib cannot be merged.

[kwinsor]

What is Veeam's recommendation here with copy to object storage as backups are created with forever incremental jobs with a single active backup chain? I'm confused right now. Support is suggesting I use an offload window outside of our backup window. At this point I need to know what Veeam recommends as a best practice in this scenario.

[Gostev]

I would agree with them (and you) that in this situation, the only way is indeed to schedule offload to work outside of your backup window - just as you suggested in your very first post. As soon as this is done, you can remove the offload window restriction, as it will no longer be necessary with only the newly created increments offloaded.

[kwinsor]

ok thanks. I found the initial offload process took a while to stop on the first attempt so I hope it will be ok when it's backup window ends. Maybe I will give it 30 min before backups begin to run.