I've recently been evacuating scale-out backup repository extents while arrays are being rebuilt and expanded. The process has an impact on backup operations but they do continue. There's room for improvement.
I'd love to hear everyone's thoughts on adding logic to the evacuation routine? I'd propose an approach where the priority is to minimize the necessity of active-fulls (due to unavailable VBK). I'm assuming per-VM files here. I really don't know how optimization might look in other cases. The basic logic might go something like:
First past, move the most recent VBK for each VM that is currently included in a backup or copy job. My theory is that having the most recent VBK available on an active extent would obviate the need for an active-full.
Next, go back and move all VIB that are part of the most current backup chain. Do this one VM at a time (in as parallel a fashion as the rules allow for). I'm guessing that partial chains aren't as useful as complete ones and so it makes sense to finish each one before moving on.
Once the most recent chain for each VM is available on an active extent, go back and copy everything else.
Hi Ryan, while there is some simple evacuation logic (fulls get evacuated first), there's indeed a room for improvement if we'd want to avoid creation of new full backups on another extent. Thanks for your suggestions, much appreciated.
I did notice that the full backups go first. The simplest and biggest improvement would be to get only the newest full backup on the first round. I've been watching a single (very large) VM's fulls tie up the works for a day or so before anything else can happen.