How to properly size scratch/staging/etc locations

Question

Currently dealing with a new installation, where the expected large storage array has not yet arrived, and I need to start backups before it arrives.

Have a 10TB vmWare VM that MABS is backing up to Disk and online.

(currently contains very little date. Soon to change)

Existing temporary disk is approximately 26TB.

Assuming I need to use this temporary storage for 1-2 months, and I'm doing daily backups, how best do I partition this storage?

Actual Backup Space/Storage pool: ?

Staging Area: ?

Scratch Area: ?

The MABS server also has an additional disk that has 450GB free space. Can I use this for the scratch location without worrying about it filling up during either a backup or restore?

What limited descriptions about certain space requirements there are tells me the following: (please correct if wrong)

Scratch - Used during online backups. Seems to be a question on whether this is "temporary" storage, or if it contains metadata or other information that is retained between backups.

Staging - Used during recovery operations. Docs suggest this needs to be as large as what is being recovered. Question: Does this include doing a file or folder recovery for a VM, or only when restoring the entire VM?

Answer 1

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