Backup vs. Backup Copy retention times

[VNR-LF]

hi all,

i have received conflicting information on the topic of retention times for repositories targeted by backup copy jobs, and have not been able to find a definitive answer by myself. so i thought i might just ask here:

i have a backup repository ("repo a") that offloads data to s3 standard object storage, retention time is currently set to "keep forever". i now add a new repository ("repo b") that offloads data to s3 glacier deep archive and set the retention time to "keep forever" as well. next, i create backup copy jobs targeting "repo b" for all backup jobs targeting "repo a" in order to create a kind of "long-term archive". after all data has been copied from "repo a" to "repo b", i reconfigure the retention time of "repo a" to, say, 3 months -> keep short-term data in s3 standard, keep long-term data in s3 glacier deep archive. now to the point i have received conflicting information on: is it possible to set this up this way, or will backup copy always have the same retention time as the backup it copies (retention time from "repo a" is being inherited to "repo b")?

tl;dr:
do archive repositories inherit retention time from backup repositories, or is it possible to use backup copy to create long-term backups in lower-cost object storage repositoreis using different retention times on backup and backup archive repositories?

thanks in advance and kind regards,
lars

[Mildur]

Hi Lars

Backup Repository (Object Storage) and Backup Copy Repositories (Archive Object Storage) have their own retention setting.
The retention will not be inherited from the normal backup repository. One of the arguments to use Archive Object storage is for cheaper longer-term retention of your backups.

May I ask, where do you get the conflicting information? Was it in one of our helpcenter pages?

Thanks
Fabian

[VNR-LF]

great. this is what i was hoping for!

everything i read about this, for example in blogs (like https://www.veeam.com/blog/self-service ... t-365.html) and the helpcenter documentation etc. made me believe it is like you just confirmed. i got the conflicting information from "Veeam Support - Case # 05596961":

"Unfortunatelly the behavior described by you, is not possible.

The glacier repo, will also copy the retention of the main repository.

So switching the retention from keep forever to 3 months, will also impact the archived tier repository."

or maybe i misunderstood? i do not mean to point fingers here!

anyway, good to know this is the solution to save on storage costs i was looking for! time to copy those tbs of historical data from s3 standard to glacier deep archive!

kind regards,
lars

[Mike Resseler]

No, I think you understood correctly and it was one of the main scenario's for us. Most restores (95%+) come from the first 30 days of data and 97+ from the first 90 days. So in most cases, storing the data on fast storage (primary) for a shorter period (between 30 and 180 days or depending on your SLA's) and then have a copy of everything for multiple years is what we were aiming for. Note, this is not archiving because it is also part of our 3-2-1 philosophy.

[Mildur]

Thanks for the case number. It's important to us, that our information is consistent on all platforms
I have done a short test in my lab.
- Azure Blob 7 Days
- Azure Blob Archive 180 days

My data in Azure Blob Archive is still accessible for the last 180 days.
So it works as advertised on our website and Mike/me have explained.

Thanks
Fabian

[VNR-LF]

that's really good to know, thank you very much! i'm still working with support to make the copy jobs work (they don't, yet...), but i have one more question:

i have been using vbo for more than 2 years and have backup data from users that are no longer with us in my repositories. i am supposed to be able to access this data in the future and thus need to copy everything to long-term storage. since they left, their data is no longer being processed by the daily backup jobs. will this data still be copied to the archive repositories by the backup copy jobs?

kind regards,
lars

[Mildur]

Hi Lars

Yes, please continue to work with support for the other issue.

since they left, their data is no longer being processed by the daily backup jobs. will this data still be copied to the archive repositories by the backup copy jobs?

For the other question, let me check in my lab. I believe no, because we copy data from a backup job as a source, not from a backup repository. But I want to be sure about it.

Thanks
Fabian

[Mildur]

Hi Lars

Finally I had the time to run the test.
A new Backup Copy Job only copied the latest restore point and not the entire source repository.
This also means, only users processed by the last backup job run will be copied to the archive storage.
I did the test for a repository with snapshot based retention.

Thanks
Fabian

[VNR-LF]

thank you very much for testing! too bad it has been working the way you already expected. i'm using item level retention btw.

i would really love to start using glacier deep archive repositories for long-term retention, but losing the "historical data" from former employees i currently have in my s3-standard repositories is not an option. i wish backup copy would have been there from the start... do you (or anyone else) have any idea if there is another way to achieve this? like running powershell to "read from standard repository and copy evereything found to archive"? could this maybe be a future feature?

thanks again and kind regards,
lars