Incorporating Ransomware Protection into Backup Plan
I don’t fully understand or trust incremental / incremental + block level backups.
Basically they record changes since the last full backup. So if you back up ten files today. Then one file changes. And you take an incremental backup, you only additionally back up the one file that changed, not an additional backup of the ones that didn't change that you already have backed up.
Large incremental backup array with an airgap only coming online for backups (Possibly manually done on a weekly basis). Phrases like “incremental backup decreases recovery reliability.” terrify me because I’ve been the brunt of “it should have worked but didn’t” in this exact scenario (although this was years ago).
Incrementals don't have real risks like that. If you've been burnt in the past, you need to identify what actually failed. Incremental backups are trusted by every major company and no one worries about them failing. Incremental failures and almost exclusively caused by people who literally lose their backups and can't find them. If you take a full, and lose it, it'll be gone, too.
Large incremental backup array with an airgap only coming online for backups (Possibly manually done on a weekly basis).
Not really an air gap in the situation. If it is online ever, it's not air gapped. It's a nice additional precaution, but don't consider it an air gap.
My understanding is the processing time of calculating differences is likely to be difficult for this size & this many files - as well as the restore. I like being able to look at / open / copy files.
Sure, but the time to back them up is there, too. So that's not a consideration. There is no reasonable reason to avoid incrementals / differentials. If you can do what you need using nothing but Fulls, that's perfectly fine. But don't think that there is any technical reason to not use them, they are completely safe and fast.
I know that if the network doesn’t have authorization - ransomware shouldn’t be able to touch it - but I like 'can't' more than 'shouldn't' - (Tape Drives or smaller self contained arrays that have even less connection time to the network).
If you can back up to it, ransomware can get to it. The two go together. You can't separate the two.
I’m also skeptical about the processing time for 30 mil small files. (Maybe I’m wrong about this?) This would have to include a software solution (Veeam, Cloudberry, HP StoreEasy has free Carbonite software)
Not all backups look at individual files. Many, maybe most, look at blocks not files, and just see a single file system to back up and have no concern for the individual files.
Some people have said IT moved away from them because they weren’t reliable, slow to retrieve individual files etc.
Those people aren't in IT and are out of touch with the universe. Tapes are still the "go to" backup medium for companies bigger than the SMB. Only in the SMB where loads of myths tend to take hold does anyone think this. Tape is the most reliable, fastest overall speed. Yes, tapes are slow for individual files, but if you need your backup media to retrieve individual files in most cases, your system is poorly designed.
First, most companies rarely need individual files restored. If this is coming up with any frequency, something is wrong. And essentially any serious backup solution has a way to retrieve nearly any file without going to the final backup media. There is almost always a cache layer between the live systems and the untouchable backup storage that allows for screaming fast file recovery without needing to retrieve the archival media whether tape, disk array, or cloud storage.
4 Small(er) weekly backup arrays. Weekly rotating backup that involves physically connecting to the network, starting the backup & unplugging when done. Configuration would probably be 4 DL380 G8s + 48 used/refurbished HGST He8 drives in a small cabinet with a KVM & an actual person weekly backup task (only 1 computer would touch the network per week)
$8K hardware + software
Anything that involves "weird" solutions like connecting arrays or networks when needed should be ruled out. One of the most dangerous things you can do is try to reinvent the wheel when big business has had trillions of dollars of research and decades of experience and knows how to do backups well. Learn from the industry, don't try to work around it. Nothing in IT should work this way, it's an established industry with deep knowledge. Just make sure you follow good IT practices and not sales people trying to make a quick buck at your expense. But at no point should you feel that you are engineering unheard of solutions that no one else has or needs, guaranteed that means something is being overlooked or misunderstood.
Rule all of this stuff out right away. Tape, Write Once, and similar solutions are what you use. Nothing else.
Other solutions - OneBlox? I know people over at Spiceworks were big fans of OneBlox which seems to have morphed into StorageCraft. I think OneXafe is what I’d be looking at which seems to be a Hardware + Software in a box solution.
OneXafe $15K - $40K
StorageCraft bought them because they wanted a write once hardware platform to target backups to. Not cheap, but a great product.
We have two servers. A production server that has 30TB / 30,000,000 files with 1 - 2 TB that rotates on / off weekly basis. This server also has a 30GB production SQL Database.
At this size, tape is the answer with extremely rare exception. A solid D2D2T stock "by the book" solution is the best for almost everyone, and for you, too. It's affordable and solves every concern that you have. You have disk for rapid file restores, and tape to protect against ransomware.
Obsolesce last edited by Obsolesce
A solid D2D2T stock "by the book" solution
This is exactly the method I've used to provide a solid backup solution for a similar situation. A total of ~45 TB of data with multiple SQL database and VMs. The DBs were backed up via built-in methods, but were also backed up "as a whole" as part of the VM backup (but that's besides the point).
This gave quick and efficient local on-prem backup and restores, and also allowed for off-site rotation.
Daily incrementals were done on-prem, whcih was quick using veeam with it's block change tracking.
I did NOT use their synthetic fulls because those took ridiculously long and and on top of that it just seemed like a very volatile process at those sizes, because the daily incrementals could be TB+ sizes. So daily incerementals to on-prem backup repo, weekly fulls to on-prem backup repo, monthly backup repo to tape to off-site. There were 3 or 4 tape sets, so that allowed nearly 6 months of retention of daily backups. Some of the DBs were backed up via built-in methods so because of that we also had hourly DB backups for some DBs for ~6 months (rougly speaking).
And yes, do pay the fee to bring in a tape from off-site to test restore a production system and some data in a test environment. I did this a couple times with success, but you never know.
Appreciate all of the input. This is the solution I've been leaning towards over the last week. Had an infrastructure hiccup & haven't been able to spend any time on this. But I will utilize my existing backup device for the backup disk & incorporate standard LTO-8 drive library with a rotating weekly offsite storage.