![]() ![]() I also need to make sure that I'm keeping data in Wasabi for at least 90 days as I recall to prevent additional charges for deleting data too soon. ![]() The downside being, that as far as I know, I'd need to create two local repositories, one for backups, one for copy jobs, and then rather than apply GFS retention to the backup job, apply it all to the copy job so that I'm not duplicating my data since both repositories will be on the same disks. I'm wondering if it makes more sense to actually use the SOBR with a copy job that would keep more of the longer term data in the SOBR via GFS retention. The sizes are fine really as we're looking to use Wasabi as an off-site copy, but not necessarily a long-term archival. However, I'm now realizing that the amount of space contracted with Wasabi is less than the local repository (3TB vs about 10.5TB) and I believe I'll be filling up Wasabi well before I fill the local disks since, as I understand it, I can't use a the wasabi extent to store different data than what is in the local extent like I would do with copy jobs to a cloud connect repository. I have a couple of questions as when I did this as a POC, I backed up directly to the SOBR with instant copies to Wasabi as a capacity tier. I am setting up a SOBR with Wasabi for offsite backups for the first time in production and nearly all of my experience with offsites is copy jobs to Iland as a Cloud Connect repository, but we're wanting to use Wasabi as a cheaper solution for offsite copies. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |