VeeamON 2024 - Use Code "COMMUNITY10" for 10% Off!
Geoff, I will be briefing your PM folks about the upcoming SOSAPI updates soon. While I can’t share them publicly yet, we can provide them to you under NDA. For everyone else, when I can share the SOSAPI updates I will do so here. ThanksSteve
can you please explain the process of deleting the unwanted immutable backup in Governance mode? Is this done from the S3 bucket end or from VBR server end? All deletions are issued via VBR. Nothing should be manually deleted from a bucket used by VBR,VB365, etc…. Our software applications should be the only thing issuing deletions. Hope that answers your question. Steve
Thank you for the useful experience and sharing @SteveF May I ask what the procedure is for restoring/recovering data from the archive level? Is it necessary to move to capacity level first? When you do the restore from the archive tier, VBR will handle all of the work to get the data restored for you. You don’t need to do anything other than selecting what you want restored. Here are the instructions for Restoring from Archive Tier. As you said, the backup that is entered at the archive level is a full backup based on the GFS scenario that we created. My question is how do I create a scenario that in a year there are 4 full / GFS backups? and what happened in the following year? You would just need to schedule within VBR the creation of the 4 GFS backups during the year based upon your requirements. A great explanation of VBR’s GFS backups can be found here: VBR + GFS Backups Hope this helps. Steve
just thinking, archive tier isnt visible in the SOBR so I assume its not compatible with the performance or capacity tier…..so we have to use backup copy jobs Do you have an archive tier repository available to be used by the SOBR?
Another option is to use VBR’s Archive Tier feature. It enables you to send GFS backups (weekly,monthly, yearly) to a cold storage tier of object storage. This includes AWS S3 Glacier, Microsoft Azure Archive Storage, and new with VBR v12.1 on-prem cold s3 compatible storage.
My apologies. I read StoreOnce, but my mind processed StorageGrid. I hate Monday mornings sometimes and this is one of them.
When using S3 object locking apis, there are two retention modes:Compliance GovernanceThe details of these retention modes can be found here S3 Object Locking. The major difference between these two is Compliance Mode doesn’t allow the removal or reduction of object lock retention once an object is written. Governance allows that type of manipulation if they are given permission to do so. Prior to 12.1 VBR only supported Compliance Mode, but due to the scenario of this topic we saw the need/use case to support Governance Mode in 12.1.
@Andanet You may want to check with HPE to see if they have any capabilities to help you out. I misread the product you were using and thought it was an object storage platform that has a slightly similar name
As everyone else noted here, Four Eyes is the way to go. That said, you’ll want to make sure that nobody has access to the back-end storage as well to where the actual backup files can be deleted behind the scenes. You are correct that the data needs to be protected as well. That is why you should use immutability via hardened Linux repositories and/or S3 object lock. Immutability + four eyes authentication will help protect the data from the rogue administrator.
VBR 12.1 introduced Four Eyes Authentication which will help you with your concern of a rogue admin deleting backups.
Hello, Could you tell me why i shouldn’t do a move from performance tier on sobr with object storage on performance tier? Is it a software limitation or related to best pratices? Limitations for Archive Tier - User Guide for VMware vSphere (veeam.com) @BertrandFR the software will allow you to archive directly from the Performance tier when it is comprised of object storage. My intent was to bring to your attention that if you move the GFS backup from the Performance tier to the Archive tier, you will only have 1 copy of that GFS backup which doesn’t satisfy the 3-2-1 rule.
@DrObject, thanks for the question. Veeam’s best practice and recommended block/object size is 1MB which you can find in our HelpCenter documentation for Storage Optimization. When using larger block/object sizes like 4MB, we have seen storage increases of 2x or greater. The larger the block/object size the results from deduplication and compression will be significantly reduced.In this scenario, you are moving from XFS who’s default block size is 4KiB (4,096 bytes) so the deduplication is expected to be greater than when using 4MB (4,000,000 bytes).As far as the deletions are concerned, we do reuse some objects are references for future backup chains due to our use of fast-cloning to reduce duplicate objects. So if you have a 3 week retention period, it isn’t expected that on week 4 you will see an entire week’s worth of storage reclaimed. Over time, backup chains that are no longer being used will be removed.As always if you feel that something isn’t working as designed, please
My use case will probably be: centralise backup for several hundred ROBO. backup copy => SOBR with performance tier on object storage/standard storage class and archive tier for storage class glacier @BertrandFR, the Archive tier isn’t a copy of the Performance tier, however the Capacity tier with copy mode enabled is a copy of the Performance tier. So to preserve the 3-2-1 rule, you shouldn’t go directly from the Performance tier to the Archive Tier. Also, the source of the Archive tier needs to be object storage backed repositories. If you decide to go to the Archive tier directly from the Performance tier, the Performance tier will need to be object storage backed.My example of Performance tier → Capacity tier → Archive tier, is the best approach and also maintains the integrity of the 3-2-1 rule. And if you use immutability in your tiers, then the 3-2-1-1-0 rule is satisfied.Hope this helps.
Interesting article, this has given me a good trailer of what my configuration will look like, but with a different solution :) I would have preferred to be able to choose move or copy maybe both like the archive tier. Have you tested backup copy as well? I’m curious, maybe i missed something why do you need many buckets as the storage class is different? How long Blackpearl is waiting to send data to tape? is there a stagging zone? @BertrandFR I am not sure I understand your question. There is no option to copy/move to the Archive Tier. Perhaps you meant the Capacity Tier? If so, the two tiers don’t have the same use cases so they don’t have the same capabilities. The Archive Tier’s use case is to store your GFS backups (weekly, monthly, yearly, etc...) on cold storage with the intention of you saving on the storage costs due to cold storage typically being the least expensive storage tier. The GFS backups are moved from the source tier, so there is no “copy” option available. I
Yes very interesting solution and explanation for sure. Thanks for sharing. Thanks @Chris.Childerhose. We are constantly innovating and iterating here “Veeam Speed”, so there’s plenty for me to share. If you have any ideas for future blogs, please reach out to me.
Actually never heard of that storage solution @SteveF 😊 Nice ‘how-to’ post on how to set it all up. @coolsport00 Thanks!!! Are you unfamilar with Spectra and/or their BlackPearl product? Check out Spectra's Veeam Landing Page for more info about our partnership. BlackPearl S3 has also been validated via the Veeam Ready Program.
Great idea and awesome demo!!! Thanks for sharing @benyoung
All very fascinating, hence my questions around what’s under the hood of Object First. Also makes a lot of sense why some features of the SOSAPI are pointless to some S3 integrations, while useful to others. @TylerJurgens you are correct that most of the features of the SOSAPI are targetted for the on-prem object storage solutions. I am not saying that public cloud offerings couldn’t use the SOSAPI, but the on-prem solutions certainly can benefit the most at this time by adopting it. Object First is a great example of that.
@MikeLeone these steps Browsing Machine Backups for Guest OS Files from our HelpCenter documentation may help you.
Yes. A SOBR can be a target for a Backup Copy job.
Check the following link to see if that helps or you missed anything - Configuring Global Notification Settings - Veeam Backup for Microsoft Azure Guide We have already checked all that, thank you Not sure what else to suggest other than a Support case at this point. Maybe check the forums for posts as well - https://forums.veeam.com An example of a post from there - Failed to send a test email: Resource could not be discovered (veeam.com) -- Not related but you might find something on the forums. As Chris noted - if you’ve confirmed your settings via HelpCenter and have checked the RnD forums, but you are are struggling with this issue then opening a Veeam Support Case is your best step forward to resolve this.
As the folks have noted above our HelpCenter has a great step by step process documented to help with this exact task. Migrating Veeam Backup & Replication to Another Backup Server
Thanks for the update Chris.
You can never have too much immutability enabled. I always recommend that all copies of the data that can be made immutable, be made immutable.
Great work!!! I can’t wait to try this in my lab
Already have an account? Login
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.
Sorry, we're still checking this file's contents to make sure it's safe to download. Please try again in a few minutes.
Sorry, our virus scanner detected that this file isn't safe to download.
