[Novalug] Very nice instructions on how to do backups on Linux
Phil Shapiro
pshapiro@his.com
Tue Jan 17 17:18:12 EST 2017
Rich, I really appreciate your insights and corrections...
----- Original Message -----
From: "Rich Kulawiec via Novalug" <novalug@firemountain.net>
To: novalug@firemountain.net
Sent: Tuesday, January 17, 2017 7:12:53 AM
Subject: Re: [Novalug] Very nice instructions on how to do backups on Linux
On Sat, Jan 14, 2017 at 06:54:40PM -0500, Phil Shapiro via Novalug wrote:
> I recently came across this. Very nicely written.
It IS well-written. However, there are a number of things in it that
are dubious or wrong. I'm not going to cover them all.
1. Use of UDF. That's an odd choice. Also it's limited to 2T (which
limits the total size of the entire backup corpus) and it's not encrypted.
If you're going to back up to external media, that media should be
encrypted. (TrueCrypt still works, but VeraCrypt and CipherShed are
now better choices.)
2. If you're using a backup server, then it should always pull and should
not allow pushing.
3. Quoting:
"You might have exclusions that you don't want to have backed up
(for instance, do you ever want your trash bin backed up?)"
and
"This section assumes that you are interested in backing up your
personal data, not the entire system, since the OS is free and
can be re-constructed."
and
"There is a case for backing up the entire system (quicker recovery
in the event of a full system disaster being the main one) [...]"
There is a solid case for covering every file on every filesystem on
every disk, unless you have a very compelling reason to do otherwise
(and you don't) so that's what you should do. Even if you have
meticulously documented the installation and configuration procedure
for every system you built...do it anyway.
[ As an exercise for the reader, and this is a real-world
example: posit a dozen identical web servers. Same hardware,
same disks, same layout, same installed software, same
configuration -- the only differences are system-specific
stuff in /etc and /var, and web content living in someplace
like /home/content. Should you back up /usr on every one
of them? ]
4. It can't do incremental backups to different media. Nor can it
do incremental backups without having the full (initial) backups
available. This means -- among other things -- that you can't
perform the full/initial backup, then disconnect that drive and leave
it disconnected until the next time you decide to do so.
5. Quoting:
"On the server, you should disable ssh-password sign-in (this
option is found in /etc/ssh/sshd_config), and consider using
Fail2Ban."
Good lord no. If you ignore point 2 and decide to allow pushing
to the server, you should not use a halfass measure like Fail2Ban.
You should firewall out *everything* and only allow incoming ssh
connections from the backup clients.
6. Quoting:
"Backing up to a server that you do not own or do not have
physical access to can be tricky [snip]"
There is a term for people who back up to operations/servers that
they don't run. That term is "victim".
7. The discussion on automating via cron is okay, but should cover
making sure that cron's output gets put in front of your eyeballs.
8. The section labeled "Dummy Checks" is a good idea, because a surprising
and disappointing number of operations have "backups" that aren't.
However, human-initiated spot checks, while a good idea and one that I also
recommend, are insufficient. All backups should be verified/cataloged
as soon as they're run. It's bad if they failed. It's far worse if
you don't find out about it for three months because you got busy and
stopped doing spot checks.
It would be much simpler and easier to just use dump (whether backups
are going to an external encrypted drive or to a local backup server).
It never ceases to amaze me how much trouble folks go through trying
to implement backup solutions that don't use dump...even though it's
designed to do backups and works beautifully *when used properly*.
---rsk
p.s. Answer to exercise: yes. Because when the day comes that someone
finds a remotely exploitable hole in PHP before you patch it, and one
of those twelve servers happens to have a web site that happens to have
PHP code that happens to be contain that hole, and that single server
gets compromised, then you'll want a complete set of historical
backups for investigatory/forensic purposes. And "we didn't feel
like burning a few gig of disk" is not going to fly as an excuse.
**********************************************************************
The Novalug mailing list is hosted by firemountain.net.
To unsubscribe or change delivery options:
http://www.firemountain.net/mailman/listinfo/novalug
--
--
Phil Shapiro, pshapiro@his.com
http://www.his.com/pshapiro/briefbio.html
http://www.twitter.com/philshapiro
http://www.his.com/pshapiro/stories.menu.html
"Wisdom begins with wonder." - Socrates
"Learning happens thru gentleness."
More information about the Novalug
mailing list