3

I'm planning a home backup setup, and I'm not sure if I really understand this quite right.

The idea is I'll set up a Linux server on the network that contains two drives. Drive1 will be network-accessible and used as a backup location for several other machines on the network as well as a general file share. Drive2 will not be network accessible, only the host OS will be able to access it, and will serve as a target location for duplicity to store incremental backups of Drive1.

My understanding is: in case of ransomware on any of the various client machines on the network (that have write access to Drive1), that machine as well as Drive1 will be hosed, but the backups of Drive1 should be safe, since only the server will have write access to Drive2 (assuming the server isn't infected and duplicity is set up to write changes, not erase existing backups).

Is that accurate?

Improve this question
1
  • 2
    You should consider your possible infection detection time compared to the overall incremental duration of your backup. No good if your files are being backed up but they are already compromised and you do not notice.
    – Overmind
    Commented Dec 5, 2017 at 8:48

2 Answers 2

Reset to default
5

Reasonably accurate. You might also let the Linux server read the files off the PCs, which have no write access to the Linux server (nor even know it's there. They're simply accessed routinely by someone reading all their data).

What you really want, though (because I saw this happen) is an emergency interlock that calculates the size of the new backup, and stops everything if it looks too large. For example if it contains ten times the average daily number of changed documents. Or better still, in that case it freezes the previous backup and starts a new chain, and emails an alert to you. Several other telltales are there: you might for example prepare empty documents ("honey docs") that no one should read. If they abruptly turn out to have changed or disappeared...

Improve this answer
8
  • Interesting. Are there any off-the-shelf products you know of that provide an interlock functionality, or should I just roll my own? Or maybe more to the point, is there a different phrase I might search to research this kind of thing? My googling didn't turn up anything useful.
    – user8675309
    Commented Dec 6, 2017 at 14:52
  • Probably you need to roll your own (as I did) because every backup is done with a different strategy. I install cygwin-rsyncd on Windows machines, and a hardlink-based timemachine on a Synology NAS. After the sync, du on the newly sinced directory alone or together with the version of the day before give me two numbers, their difference is the "backup size". The number of hardlinks with 1 ref is the number of changes, and so on.
    – LSerni
    Commented Dec 6, 2017 at 15:04
  • Just because I'm sure I don't have this straight: 1. cygwin-rsyncd runs an rsync daemon on your Windows machine to allow external rsync-ers to copy data from the Win box. 2. Your NAS syncs with the Winbox 3. The NAS makes incremental backups of data on itself using hardlinks to track data that hasn't changed (2 links means yesterday and today this file was identical), then either du on the first and second most recent copies to compare size change, or check the number of hardlinks with 1 ref (brand new data)? I feel like I'm missing something fundamental.
    – user8675309
    Commented Dec 6, 2017 at 20:00
  • du is run twice, first on today, then on both today and yesterday together. Any 'internal' hard links will be counted only once, so du will report, say, 450 GB for today alone, but then will report 450 GB for yesterday and only 12 GB for today when considered together with yesterday. This means that 12 GB of files changed in the meantime (actually less than that, as directories count too).
    – LSerni
    Commented Dec 6, 2017 at 20:54
  • I think I get it. So that only shows you a large change after you've already run a backup on the corrupted files, but at that point you'd know to pull the plug and start DR?
    – user8675309
    Commented Dec 6, 2017 at 20:58
0

This is somehow assuming that your server is not going to be infected. I don't know how reliable that assumption is ; after all, there do exist ransomware infections for linux, but I don't know their different infection mechanisms. That said, I think you're reasonably safe.

The trick I use to protect against ransomware, is a double set of removable disks. I have a server with a networked disk that is used as regular backup medium from all machines, using duplicity. Every week, I connect, by hand, one of my removable disks, and make an integral copy of the backup disk ; then I remove the disk again. I use disk A the even weeks, and disk B the uneven weeks. I know it is tiresome, but I think it is a reasonably foolproof system against ransomware and other problems. Moreover, I keep A and B in different locations.

Improve this answer
2
  • 1
    Can the person voting this down explain why ? After all, I'm pointing out that one needs the assumption of the server not being infected, and propose a way to mitigate that aspect ? Am I missing something ?
    – entrop-x
    Commented Dec 5, 2017 at 9:26
  • I don't know the downvote reason, but nearly all in-the-wild malware requires some user interaction: visiting websites, opening email attachments, downloading games from the internet. A server which only exposes network file systems and SSH is about as safe as one can get. And non-state-level malware does not sniff your every move to intercept the moment you SSH into the server to do some maintenance there.
    – quazgar
    Commented Mar 15, 2023 at 13:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .