Re: [Samba] ransomware etc
- Date: Thu, 29 Jun 2017 03:03:59 -0400
- From: Nico Kadel-Garcia via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] ransomware etc
On Thu, Jun 29, 2017 at 12:23 AM, Mike Lykov via samba
> 29.06.2017 3:58, Nico Kadel-Garcia via samba пишет:
>> Or, for oldsters like myself, rsnapshot reading from the current
>> filesystem. It's often much, much simpler to implement and lends
>> itself fell to finer tuning and restoration of old content than a
>> filesystem based backup.
> How often you are run rsnapshot ?
> And what are you doing if files are broken, but rsnapshot backed it up
> already ?
How often to run it depends on your resources and requirements. For
many applications and environments, a nightly rsnapshot to a different
server or at least to a different disk, with the last week and month
exposed in read-only mode via Samba or NFS, is far more useful than
more complex filesystem based snapshots that require additional kernel
level resources and disk on the local working host. This is mostly
because the bigger risk to most working environments isn't ransomware.
It's "rm -rf" or accidentally selecting the wrong files or directories
in a GUI.
The key to recovery with any backup system is *when* did the file
break., If it was broken after the rsnapshot, you have the old
snapshots to revert. That's part of the point of a backup system.
I've worked successfully with Samba and fielesystem based snapshot
systems, such as LVM (which only supports keeping one snspahost).
There are significant difficulties planning such snapshots for
databases: the schedule for them may not match when your database has
been completely written to disk. I've actually successfully used LVM
in collaboration with rsnapshot, to pause a database, take an LVM
snapshot, and rsnapshot from *that. That's a very good time to
snapshot that database to another host and/or separate physical media
for rsnapshot or other less expensive backup systems. on different
physical media where it's less vulnerable to hardware or kernel
failures and much less vulnerable to "Bobby Tables"
More significantly powerful snapshotting systems, like NetApp's
multiple hourly or daily snapshots, do take significant resources from
the hosting storage system. In many cases it's serous system overkill.
You can spend the hardware budget on a backup host, or on external
drives elsewhere, to provide one of the key features of a backup
system. *Get it off the live server* onto different physical media.
To unsubscribe from this list go to the following URL and read the