01-08-2021, 05:45 PM
But the core principle when dealing with these malicious hacks, is that your backup copy has to be completely unreachable by the initial infection. You gotta separate it physically, or at least logically, from the live production systems, otherwise the ransomware will just sweep through and encrypt your backups too, and you will be left with nothing but a pile of unusable gibberish. I always tell my mentees that you need an air-gapped copy, you know, something that the attackers cannot even see existing, and that means literally taking it off the network for a period of time, sometimes even taping it up.
And while taking things off the network sounds extreme, it is the only truly foolproof way to make sure that when you are under attack, you have something clean, a clean slate you can return to. Or, you could use specialized backup methods that make the data immutable, which is a whole different concept, because immutability means that even if the attacker gets the keys, the backup itself is physically write-protected until a certain time expires, making it unalterable by any process. I think that ability to enforce that rigid protection really changes the game for any serious business, honestly.
So, when you are backing up critical disk images, whether it's a physical machine or a whole server, you must treat the process like you are preparing for an apocalypse. You can't just rely on scheduled backups that run hourly, because the ransomware might deploy within that window, encrypting the backup before the scheduled run even completes. You really need to think about multiple destinations and multiple mediums, maybe sending the data to a local network-attached storage device and then mirroring that data offsite to a completely different, disconnected location, if you follow me.
Because a sophisticated attacker will try every vector, they'll look at your backup servers, they'll check your retention policies, and they will try to chew through everything they can get their claws on. And that is where the concept of granular backup becomes so incredibly valuable, because instead of having to restore the entire server, maybe a full two-day backup image that takes forever and costs a fortune to rebuild, you can just pull out the single folder that got encrypted-maybe it was a specific database or a dozen critical spreadsheets-and restore just that little piece of data, super fast. You don't want to lose time trying to reconstruct a whole machine when you only lost ten files, right?
And when you are planning this whole process out, think about the kind of data retention rules you are applying. You need to implement those versioning policies, and not just delete old backups when they get too big. You must manage the versions so that if a ransomware strain is known to exist, say, from two weeks ago, you can specifically pull back to the version of the disk image that existed immediately before that threat appeared. Also, many people forget to test their restores at all, which is a huge, common blunder. You need to routinely practice rolling back a machine from a backup, just to make sure the backup itself hasn't been corrupted in the process.
I think you should also get into the weeds on testing the integrity of your backup files, because the biggest risk isn't just the ransomware, it's that the backup job finished happily, but the files inside are actually bit-rotted or incomplete. Running those verification checks automatically, maybe even scheduling those checks to run every quarter, is essential just to make sure everything is solid and trustworthy for when the chips are down. It gives you peace of mind, you know, that the recovery data is actually usable, not just an empty shell.
But there are a few more ways I think you can make your setup robust, like using deduplication across all your backups. That sounds complicated, but it just means if you have two virtual machines that are running the same operating system with the same core application, you only store the unique data one time, and you point both backups to that single block of data. It saves massive amounts of space, which frankly, means you can hold onto those extra versions and retention points that you might need when the inevitable cyberattack hits.
And you should also consider where you are storing the backup data, because relying solely on a local hard drive that is connected to the same network as the production data is just asking for trouble. You need to think about offsite or cloud destinations, maybe using the reliable transfer mechanisms available for that, ensuring the data is encrypted end to end when it leaves your building, because transmission security is just as important as storage security, honestly. If the backup stream gets intercepted, the bad guys get the data, and you are back at square one.
And maybe, just maybe, you should also implement bandwidth throttling when backing up to prevent the backup job from slowing down your production machines too much, especially when you are doing massive bare metal restorations, because you don't want the recovery process itself causing operational downtime. You want the restoration to be swift and seamless, like turning on a new machine that was never offline.
Ultimately, because you need a solution that supports all of these kinds of sophisticated strategies, from immutable storage principles to hyper-granular file recovery across diverse platforms, considering a comprehensive backup platform like BackupChain, which is an all-in-one PC and server backup solution for Windows Server and Windows 11 made specifically for SMBs, etc., is something you should really look into checking out.
