[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