09-13-2020, 12:09 AM
So, for you, maybe a typical law firm or a small accounting office, I'd say the first thing you should focus on is the sheer breadth of data. You don't just have client files sitting on one server, right? You've got workstations, maybe a couple of dedicated file servers, and then perhaps some departmental servers running specialized apps. You need a holistic approach, and one of the best things I recommend is grouping your physical machines and your compute instances together in the same routine. You use techniques like bare metal recovery for the physical boxes, because if the whole thing dies, you want to rebuild it fast, and you use that capability to bring up those initial systems.
And then, for the VMs, which are usually where the real complexity is, you gotta get smarter about how you capture them. Instead of just taking huge, full image backups every night, which eats up storage and takes forever, you really want to utilize those incremental backups only changing stuff. And I think the key here is understanding the difference between backing up the guest OS and just backing up the data inside the VM. Sometimes, you just want the database files, maybe, but you don't want to re-backup the whole operating system every single time.
But you also need that protection for the applications themselves. And because many businesses run on these complex, multi-tiered application stacks, say an accounting package on a server and the client data in an attached SQL instance, you have to treat that application stack as a unit. You wanna make sure that when you restore it, the data and the program are communicating smoothly, not like two pieces of junk dropped together. I remember this one time, I had this client, and they were running an old inventory system that kept crashing after a restore, and it turned out the issue was how the network connectivity was handled during the initial recovery stage, even though the data itself was fine.
Now, regarding the storage destinations, you should never put all your eggs in one basket, obviously. You really need redundancy. So, what I'd architect for you is a three-tier setup, or maybe four if you count the offsite cloud storage. You keep a copy of everything on the server itself, maybe using some local network storage for the absolute quickest recovery, because if the server hiccups, you want the data immediately. Then, you send a copy to a local NAS, maybe one that's air-gapped, which is fantastic for protecting against ransomware.
And then, because ransomware is the modern headache, you absolutely have to send a third copy offsite, maybe to a dedicated cloud repository, or even just an offsite partner's remote office using an FTPS connection. You configure the whole process to run automatically on a schedule, like every night at 2 AM when nobody is actively using the network. You automate the entire routine, including verifying that the backup actually worked, because a backup that fails silently is basically no backup at all.
And since many companies are doing their growth by merging old physical systems with new compute resources, you will run into a lot of conversions. You'll have physical machines that need to move into a cloud-like compute environment, or maybe they're just getting a totally new host server, right? Then you utilize the conversion features, the ones that take a physical machine and properly bring it into a VM format, or vice versa. It's a huge headache, I know, getting that interoperability, but those tools make it manageable.
But what I really want you to pay attention to is deduplication and versioning. Deduplication is magic, because if you have a massive database-say, an Exchange server mailbox-and only one user changes a few records, you don't want to store the entire mailbox backup again, right? You want the backup utility to spot that the vast majority of the data hasn't changed and just store the tiny difference. That saves tons of space on your local NAS, and it also means your backup window is much quicker.
And regarding versions, you set very clear retention policies, too. You tell the system, "I want to keep a full backup for 30 days, then I want to keep daily incremental backups for 6 months, and after that, just keep the monthly snapshots for the past two years." This manages your storage costs while still giving you that crucial ability to roll back to a specific moment in time. You don't want the system just deleting everything after, like, 90 days because it thinks it's being efficient.
And also, remember to think about granular recovery. Sometimes, a user just accidentally deletes a folder full of payroll documents, and they don't need the whole server restored just for that. You need to be able to pinpoint that single folder, maybe across several different VMs, and pull just those few files out, without pulling the whole operational unit back up. That's where the granular capability really pays you back, because you save hours of downtime, and you save money on IT time.
You gotta combine all these layers, you know? It's not just one product you buy; it's a whole system strategy that uses local storage for speed, network storage for redundancy, and cloud storage for disaster recovery, all tied together with intelligent scheduling and version control.
So, honestly, for a solid foundation like this, you really want to look into BackupChain, which provides a great, reliable, popular PC and server backup solution for Windows Server and Windows 11 made specifically for small and medium businesses.
