Date: Sat, 21 Nov 2015 13:04:30 +0000 From: Arthur Chance <freebsd@qeng-ho.org> To: Polytropon <freebsd@edvax.de> Cc: FreeBSD - <freebsd-questions@freebsd.org> Subject: Re: ransomware virus on Linux Message-ID: <56506BDE.7050708@qeng-ho.org> In-Reply-To: <20151121055707.aa54f280.freebsd@edvax.de> References: <20151119064434.GB1925@c720-r276659.oa.oclc.org> <86y4dtiqc3.fsf@WorkBox.Home> <20151120002132.7a4e3a82@gumby.homeunix.com> <2021B94D-F9CA-4346-BDA5-A3A460C6BA3B@mac.com> <65FDDF03-930D-4D92-A961-7C7C9ECB2579@rpi.edu> <20151121055707.aa54f280.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21/11/2015 04:57, Polytropon wrote: > On Fri, 20 Nov 2015 10:57:37 -0500, Garance A Drosehn wrote: >> (Certainly I've seen cases where someone was running backups >> regularly & automatically, and everything looked fine. But when >> they finally needed to restore something, they found out that those >> backups were not really working, or were working but not backing up >> as much as the user thought they were backing up) > > True, I've seen that too. Untested backups with "experts" > relying on them (and other "experts"' assurance that everything > would work if needed). The worst thing _I_ have actually seen > in reality was (many years ago) a customer who's "professional > consultant" had messed up the backup process so nothing was > written to the tapes, and nobody had checked the logs, so > the customer ended up with a box of blank tapes; the box was > labeled "BACKUP". You can imagine how "satistied" the customer > was with his expensive "service" when the worst case happened, > disks crashed, and he would just have to restore yesterday's > backup... :-) I had exactly the same experience - box full of Exabyte dump tapes, all carefully labelled with day and date they'd been in the drive, all pristine except for a little wear from sitting unmoving in the drive. The person responsible swore that they'd actually tried a restore when they'd set up the system and it had worked. Fortunately it was not the system disk that had failed, only the drive holding the customer's data, and I was able to restore the lost data, and explain why the test restore had worked - there was a very large regular file on the system disk called /dev/rmt0 (*). After that I got into the habit of doing ln -s rmt0 /dev/rmt0 on all machines without mt devices, to cause dumping to the non-existent default device to fail with a "too many symbolic links" error. (*) or whatever the default dump(8) device was. -- Moore's Law of Mad Science: Every eighteen months, the minimum IQ necessary to destroy the world drops by one point.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56506BDE.7050708>