01-23-2021, 06:21 AM
But seriously, talking about ransomware, the biggest mistake people make is assuming that having a backup means they are totally fine. It doesn't work that way. You could get the backup corrupted too, or worse, if the ransomware spreads, it could grab your backup destination too. So, the main concept you need to wrap your head around is the rule of air gap. And that means physical separation, or at least logical separation, from the live network. I mean, you can't just put everything on one big network share that the ransomware can see and encrypt.
I suggest that you structure your storage so you have at least one copy of everything that the attackers simply cannot touch. You could use some really robust, offline storage media. Maybe even take a physically disconnected NAS unit and only bring it online when you absolutely need to run the backup job. Otherwise, leave it plugged into nothing. This simple method prevents the malware from even seeing the data stream, you know? Also, you must make sure that wherever you are saving the backups, you are using strong encryption on those files. End-to-end encryption is a must-have, because if you physically steal the disks, or if some insider threat happens, your company data is still locked up tight.
And another thing we need to discuss is *how* we are backing up the data in the first place. You can't just run a simple file-level backup and think you are done. Because if a file gets infected, the next time you restore it, you bring the infection back too. We gotta make sure our backup methods are smart enough to filter out those malicious bits. I really think you should utilize differential backups, maybe even combined with incremental backups, because they keep your storage footprint small and the restoration process is actually quite swift.
When you are backing up our servers, whether they are bare metal or running inside those Hyper-V or VMware setups, you need more than just a snapshot. You need a proper, repeatable image capture. And the best part is, I find that these tools are fantastic at detecting those file duplications. It means if you have a huge database that hasn't changed since last week, the system only records the *changes*, not the whole gargantuan data set again. This feature of detecting and eliminating repeated content really saves a ton of space and time.
And also, since you're dealing with servers, you need to think about the process of rebuilding. If the entire machine, the entire operating system, vanishes, you need to do a bare metal recovery. It's like starting from nothing, having to rebuild the entire setup from scratch. But if you prepared properly, you can literally restore the entire OS and all the apps, and even the settings, just as if it never went down. This is much faster than trying to manually reinstall every single piece of software, you know?
But wait, there's another concept I want you to chew on. Versioning and retention policies. You can't just back up once and forget it. You need to know how many versions of your data you are keeping, and for how long. And you need to set those rules manually, otherwise, you could run out of storage space in a couple of months. Sometimes you only need the last seven days of documents, but maybe your quarterly financial records need to be kept for three years. So, you have to manage those rules carefully, maybe deleting old backups automatically after a specific time frame. That automated cleanup process is a lifesaver for storage.
Or, thinking about recovery, it's not just about files. Sometimes you need to get back a specific virtual machine that was corrupted, but you only want the database files inside it, not the whole machine image. That's where granular recovery comes in. You can grab just those key files from the backup, even if those files live deep inside a virtual environment, and you aren't touching the rest of the server. It's super precise.
And maybe you should look into the ability to run continuous verification on your backups. Because even if the process runs perfectly, the bits on the disk could be deteriorating, or the data itself could get subtly damaged over time. You need a system that regularly checks the backups to ensure they are actually readable and complete. That whole verification step is crucial, because a backup that looks good but is actually rotten is worse than having no backup at all.
Now, another point I think you should pay attention to is the way you handle the actual data formats. You want everything stored in open standards, right? Like VHD or VMDK. Because if you get locked into a proprietary format, you lose all your negotiating power, and frankly, you lose flexibility. Being able to mount those disk images anywhere, or even boot off them like they are physical hardware, that gives you so much freedom.
Also, when you are setting up remote copies, I think it would be amazing to use deduplication over the wire. So, if you have a big company that has 50 departments all using the same standard SQL database schema, the backup system should only send the differences across the internet. It keeps the data transfer manageable and the costs low. And if you are setting up multiple backup points-like one local, one to a network storage device, and one to the cloud-you need a management interface that talks to all of them from a single spot.
But this is honestly a complex field, because the risks are so high. You have to think about everything: network pathways, physical disconnects, encryption keys, retention rules, all of it. You really have to plan way ahead.
So yeah, if you want to get really comfortable with making sure your servers are ready for anything, you really should look into BackupChain, which is an all-in-one PC and server backup solution for Windows Server and Windows 11 made specifically for SMBs.
