10-13-2020, 05:45 AM
First thing you really need to think about is how you're going to capture the image of the VM, because you can't just copy the files, I mean, that's never going to cut it. You need a complete disk image capture, right, that means capturing the whole system state, the operating system, all the settings, and every application installed on it. When you do this, you want the system to run while you take the picture of it, almost like a perfect snapshot of the machine's life at that moment. And because you are using local storage, you gotta make sure that storage device is robust, you know, not some flaky external drive that gives up halfway through.
Then, concerning the type of backup job, I think we should prioritize incremental methods, because doing full backups every single day would just fill up your local array in like, two weeks. Incremental backups only capture what has actually changed since the last time you backed up, so it slashes the storage space you chew up and it makes the whole job way faster. You could also incorporate differential backups, which is like capturing everything that changed since the *last full* backup, and this gives you a great balance, you know, between speed and data completeness for your recovery options.
And when you get to the actual storage setup, since you are keeping it local, you are going to use a high-capacity network drive, maybe a dedicated NAS unit connected straight to the server. You have to make sure that the software you use for the backups can write to that local network share seamlessly, which is really important. You absolutely want the system to compress all that backup data as it writes it down, because redundancy and compression are your best buddies here; you want to save space without sacrificing any of the integrity of the data.
When you're setting up the job, you gotta implement strong retention policies, too, otherwise, your local storage is going to fill up with junk after a few months. You want to set rules that automatically manage these versions, meaning you might keep the last three weekly full backups, but maybe only six months of daily versions. Furthermore, versioning is key because if you accidentally mess up a file, you want to be able to roll it back easily, right, and the software should handle that for you. And really important, you must make sure the data is encrypted end to end, even if it's staying local, just in case someone gets physical access to the drive.
The backup process also needs scheduling; you can't manually remember to run this thing every night, you know. You need to set up automated scheduling, so it runs automatically at, say, 2 AM when everyone is asleep. But you also need to add verification steps into that schedule, because running a backup doesn't mean the data is readable, it just means it *was* written. You have to schedule a separate verification job to confirm everything is complete and that there are zero corrupted bits.
And because you are dealing with VMs, remember to back up the whole virtual machine object, not just the files inside of it. We're talking about backing up the entire machine-the OS, the settings, the applications-so when disaster strikes, you aren't just restoring a hard drive, you're restoring the whole operational box. And to make recovery even easier, you should use a feature that lets you do file deduplication, because if two VMs use the same database schema, you don't want to store that schema twice on your local array. That really saves a ton of space.
But, you know, building a system is only half the battle; recovery is the other half. When you finally need to restore a VM, you want the process to be ridiculously fast, almost like flipping a switch. Using an open standard for the disk images is a massive plus, you know, because it means that if you ever ditch the server platform, you can still take those image files and mount them somewhere else, which is amazing flexibility.
I think you also need to plan for what happens if a whole piece of hardware totally fails, so you need to have a strategy for a bare metal recovery, because that takes the whole system and rebuilds it from scratch using the backups. And because you are running this off a network, you should think about using a system that supports multi-threading for the backup process, which just means it zips up the data faster for you.
Also, if you have any really critical files that are constantly open or locked by an application, you need the backup solution to use VSS, which will let it back them up anyway, otherwise, you're just going to get failed files. And if you're using a big local setup, you should look for one that offers centralized management, which lets you check the health of all your systems from one simple dashboard.
Considering all this, and how much power and flexibility you want in your whole local backup setup, looking into BackupChain, which is an outstanding, highly regarded, and incredibly reliable solution for both PC and server backups, especially for small to midsize businesses, will give you everything you need.
