Hello @Beitler, David Thank you for reaching out to us on Microsoft Q&A platform. Happy to answer any questions you may have!
From the title of the thread, I understand that you want to know the best way to manage the size of scratch/staging locations.
Scratch folder for Online backup - https://learn.microsoft.com/en-us/azure/backup/backup-azure-file-folder-backup-faq#what-s-the-minimum-size-requirement-for-the-cache-folder-
Staging area is meant for downloading the data from online restore.
Adding and removing, disks from a storage pool where exists backup repository from MABS is not healthy since MABS will utilize the pool no matter what disks resides on it.
So, if you remove a disk from a pool and we have data on that disk, you will lose disk data potentially. There is no way to define which disk to utilize on the storage pool. The pool is seen on windows as a disk and not as a disk with XYZ partitions.
What you can do is to use, two storage pools which at the end will result in two different disks and move the data from where backups from ABC server are. MABS do have that capacity and then remove it.
We are now out with UR4 for DPM 2016. There are a couple of quick notes on the features it has added - https://techcommunity.microsoft.com/t5/System-Center-Blog/SC-2016-DPM-UR4-Migrate-Backup-Storage-in-3-simple-steps/ba-p/351842
We now have a tool which can migrate a data source using MBS from one volume to a new one.
- This migration is per data source.
- Migration can take a long time (3-4 hours for 40 gig is expected)
- Any ad-hoc jobs for entire DPM server will fail while migration is happening (this includes restore jobs)
- Scheduled jobs for all data sources in this protection group will fail
Hope this helps. Feel free to reply if you have any further questions!
If the response helped, do "Accept Answer" and up-vote it