Backup Cache Storage - possible?

[jmc]

hello,

i would like to ask if anyone has ever thought about cache backup storage.

Background:
we have quite a lot of vm's and therefore also a lot of backup storage. this backup storage is equipped with 10k SAS disks in raid-6. the whole thing over 15 magazines (enclosures) with 25 hard disks each.

I have now thought about how to make the whole thing even faster and thought about the possibility of using an SSD enclosure as a cache.

so first everything should go on the ssd until the job is finished. then the migration to the actual backup storages can take place in peace. then the ssd is free again.

the solution via the backup copies is not suitable, as the backups are then marked as copy jobs and the actual backup job on the ssd is difficult to handle. deleting is also a problem. ok, it would work via script after the successful backup copy, but it is far too error-prone and difficult to administer.

maybe i think it's too complicated and there's a simple solution. or something with tiering.

i have a node in my head for now and think it's a good idea to ask in the forum.

thanks
jeff

[david.domask]

Hi jmc,

Idea is clear, and just to avoid burying the lede, right now tiering in the way you're discussing is not directly configurable, but I can imagine a fairly "simple" workaround. The current tiering with Scale-out Backup Repositories works with Capacity and Archive tier, and Backup Copies are meant for the use case you're imagining.

Can I ask, I know you said Backup Copies weren't suitable, but I maybe am not quite getting the major complications for you and what limitations you're facing. With Immediate Mode Backup Copies (default for some time), new restore points from the primary jobs will be copied as they're created. I understand you likely have limited space on the SSDs, but since Backup Copies have their own backup sets (it's not just copying the VBK/VIBs, it's reading data out of the backups to create a stand-alone backup chain for the backup copy), this means you can have shorter retention on the primary jobs and longer retention on the Backup Copies without missing any data from the primary job -- the Backup Copy job will read data from the new restore points, copy it to the Backup Copy chain which has its own retention, and that should keep your primary backups "light" without having gaps in your protection.

I can imagine there are other elements that might be a 'hiccup' for this plan, but if you could share your thoughts on the idea above, would be appreciated.

As a workaround, I suppose you could consider playing with Maintenance Mode and Evacuate Backups. While this would require a bit of juggling of which extents are in maintenance mode, you could effectively achieve what you're looking for, though I must admit I am not fond of this just because of complexity and likely you'll need to do some scripting.

So I would ask your thoughts on Backup Copies again with the above commentary and share which items would be blockers for you, as I think this would probably be the simplest and cleanest solution assuming no other blockers.