-
- Enthusiast
- Posts: 39
- Liked: 4 times
- Joined: Nov 14, 2019 7:12 pm
- Full Name: Chris Lukowski
- Contact:
GFS on Backup Job vs Backup Copy Job
We recently added Wasabi Cloud Storage to our infrastructure to complement our offsite secondary repo server. I would like to start using GFS retention but now see we have the option to perform this on the primary backup job as well as the backup copy job. I intend to keep the GFS copies only on our cloud tier to leave room for more recent backups on our primary and secondary on-prem storage. What are the pros/cons to consider when deciding which job to attach the GFS policy to?
-
- Product Manager
- Posts: 9848
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: GFS on Backup Job vs Backup Copy Job
Hi Chris
From my view it doesn‘t matter if you offload the backup job or the backup copy job.
I wouldn’t use the backup copy job, if you only have a linux hardened repository at the offsite location. That would lead to unnecessary traffic. Linux harden repos cannot offload directly to object storage. Veeam would use the backup server in the primary location. Offload traffic would flow from the offsite location to the backup server in the primary location to wasabi.
Regarding to your use case, you have to configure the capacity tier with the move policy combined with copy policy to immediate offload all new restore points.
I would set the operational restore window to 7 days.
Then you have some restore points for 1-2 weeks locally for faster restores and everything older than 1-2 weeks will be removed from the performance tier.
Thanks
Fabian
From my view it doesn‘t matter if you offload the backup job or the backup copy job.
I wouldn’t use the backup copy job, if you only have a linux hardened repository at the offsite location. That would lead to unnecessary traffic. Linux harden repos cannot offload directly to object storage. Veeam would use the backup server in the primary location. Offload traffic would flow from the offsite location to the backup server in the primary location to wasabi.
Regarding to your use case, you have to configure the capacity tier with the move policy combined with copy policy to immediate offload all new restore points.
I would set the operational restore window to 7 days.
Then you have some restore points for 1-2 weeks locally for faster restores and everything older than 1-2 weeks will be removed from the performance tier.
Thanks
Fabian
Product Management Analyst @ Veeam Software
-
- Enthusiast
- Posts: 39
- Liked: 4 times
- Joined: Nov 14, 2019 7:12 pm
- Full Name: Chris Lukowski
- Contact:
Re: GFS on Backup Job vs Backup Copy Job
"Offload traffic would flow from the offsite location to the backup server in the primary location to wasabi."
Luckily that isn't true. The SOBR I created that points to the offsite server is also the one with the Wasabi cloud tier so offloads flow directly from the offsite server to Wasabi.
I'm also thinking that I WILL reconfigure the jobs so that my primary jobs use the SOBR with the Wasabi cloud tier and GFS and I'll use a Backup Copy job -only- for the shorter-term secondary offsite copies. Referencing old backups would be easier from the primary job anyway, I think. Any other downsides to this that I should be aware of?
Luckily that isn't true. The SOBR I created that points to the offsite server is also the one with the Wasabi cloud tier so offloads flow directly from the offsite server to Wasabi.
I'm also thinking that I WILL reconfigure the jobs so that my primary jobs use the SOBR with the Wasabi cloud tier and GFS and I'll use a Backup Copy job -only- for the shorter-term secondary offsite copies. Referencing old backups would be easier from the primary job anyway, I think. Any other downsides to this that I should be aware of?
-
- Product Manager
- Posts: 9848
- Liked: 2607 times
- Joined: May 13, 2017 4:51 pm
- Full Name: Fabian K.
- Location: Switzerland
- Contact:
Re: GFS on Backup Job vs Backup Copy Job
True, as long you don't use Linux hardened repositories, the backup repo server will offload the data to S3. If you have a linux hardened repo as a performance extend, another managed server (Linux or Windows) must do the offload.Luckily that isn't true. The SOBR I created that points to the offsite server is also the one with the Wasabi cloud tier so offloads flow directly from the offsite server to Wasabi.
Seems good to me. I can't think of any downsides.I'm also thinking that I WILL reconfigure the jobs so that my primary jobs use the SOBR with the Wasabi cloud tier and GFS and I'll use a Backup Copy job -only- for the shorter-term secondary offsite copies. Referencing old backups would be easier from the primary job anyway, I think. Any other downsides to this that I should be aware of?
Product Management Analyst @ Veeam Software
Who is online
Users browsing this forum: Bing [Bot] and 121 guests