[ale] Backup questions -- what to back up?

[Jim Kinney]

On Mon, 2016-02-29 at 15:52 -0500, Derek Atkins wrote:
> Hi,
> 
> I should have said that this is for daily, automated backups, however
> my
> expectation is that I would only restore for disaster recovery.  So I
> guess my questions remain:
> 
> - what exactly do you backup?
> - what specifically do you exclude?
> 
> In terms of your package lists, do you just do the equivalent of "rpm
> -qa
> > 
> > sort > /root/package-list" when the backup begins (or perhaps at a
> > daily
> cron job)?  Or do you do something... different?
That works just fine. The anaconda install file gets backed up and can
easily be turned into a new install master kickstart. Add the rpms from
the rpm -qa list and you're ready to go.
> Do you exclude e.g. the RPM (or apt) package directory/database?  Or do
> you exclude all of /var/lib?
> 

No. A disaster restore is a fresh install plus recovery of config files
and user/system data. Let rpm "do it's thing".
> Also, how do you handle programs that might not have been installed by the
> package manager?  Do you install those manually after a restore?  Or do
> you add them to the backup?
> 

Depends on the complexity. Often those are in the user dirs as src
files so a 'make install' is all that's needed to put them back. I do
backup config files so the restore will put those back.
Think of this way - fasted way back to running for me is a fresh
install or all packaged goods, restore of system config files (/etc),
reboot (now machine has correct "personality"), restore user files,
rerun make install as required, restore custom config files, reboot, go
home.
> In my case most of my systems are vmware guests (I do have a handful of
> physical systems, but most of those are less accessible).  So in the case
> of a system being hacked, I can bring down the vm, create a new one, and
> then restore into it.
> 
> My backup server hardware arrives Thursday, so I'm trying to have all my
> scripts lined up so I can deploy quickly.  I got burned recently when an
> SD card broke (without a backup) and I lost my SIP server.  This project
> is to mitigate future such firedrills.
> 
> Thanks,
> 
> -derek
> 
> On Mon, February 29, 2016 2:57 pm, DJ-Pfulio wrote:
> 
> > 
> > For nominal, daily, automatic, backups, I do the selected areas and keep
> > a list of packages (dumping any SQL DBs first).  In my testing of
> > restores, servers are working again in less than 45min.  This is about
> > the same amount of time having a bit-for-bit backup takes to restore for
> > me, without the huge waste of storage.
> > 
> > There is an issue with this method - if the box was hacked, important
> > information may not be included in the backups, so steps to mitigate the
> > break-in may not be possible.  I've seen where /tmp/ was used for
> > hacking scripts because the userid couldn't write anywhere else on the
> > box.  I don't know anyone who backs up /tmp or /var/tmp.  Do you?  The
> > scrips where after-the-break-in, but perhaps looking through them would
> > have provided hints to the attacker?
> > 
> > If it was a 1-time thing and I needed to restore ASAP, I'd do a complete
> > backup of everything (minus "special files") - using rsync. Restore is
> > just to rsync back the OS onto a new HDD, then do a grub-install and
> > update-grub - reboot and be happy.
> > 
> > When moving systems and taking the old HDD with me isn't possible, the
> > rsync method is what I use.  It often takes longer, but it is possible
> > to run the rsync's with the running system as the source, before the
> > final "good" rsync is run without the source file system active. This
> > can drastically reduce downtime to just a few minutes when swapping HW
> > completely.  The 1st rsync might take 15-90 minutes, but the 2nd one is
> > usually under 30 sec.  The only time that doesn't work is when huge
> > files are being synched, IME.  Large files seem to force rsync to copy
> > everything again instead of doing diffs.  Nothing you and Jim don't
> > already know.
> > 
> > Plus rsync behaves differently with local disk vs network copies.
> > Surprised me when it copied everything rather than doing diffs - sorta
> > defeated the purpose for using rsync. There are options to control this,
> > but the defaults ARE NOT SANE for local copies, IMHO.
> > 
> > Since all my production systems run inside VMs, being able to move to
> > another VM host isn't hard.  The physical machines aren't anything
> > special and have a fairly stock setup.  /var/lib/ just gets extra
> > storage. ;)
> > 
> > On 02/29/2016 12:12 PM, Derek Atkins wrote:
> > 
> > > 
> > > Hi,
> > > 
> > > I'm working on configuring some backups via rdiff-backup, and I've got
> > > some style questions.  My main question is: do you back up /bin,
> > > /usr/bin, /lib, /usr/lib, and other "system" directories?  Or do you
> > > only backup /root, /etc, /var, and select areas, and keep a package list
> > > of the installed packages?
> > > 
> > > If you do backup the system directories (/bin, etc), what's the best way
> > > to restore the system?  I'm thinking disaster recovery, not "oops, I
> > > deleted a file and need it back"?
> > > 
> > > Thanks for your guidance,
> > > 
> > > -derek
> > > 
> > > 

> > 
> > 
> > 
> > --
> > Got Linux? Used on smartphones, tablets, desktop computers, media
> > centers, and servers by kids, Moms, Dads, grandparents and IT
> > professionals.
> > _______________________________________________
> > Ale mailing list
> > 
Ale at ale.org> > 
http://mail.ale.org/mailman/listinfo/ale
> > 
> > See JOBS, ANNOUNCE and SCHOOLS lists at
> > 
http://mail.ale.org/mailman/listinfo
> > 
> > 
> > 

> 
> 
> 
> 

-- 
James P. Kinney III

Every time you stop a school, you will have to build a jail. What you
gain at one end you lose at the other. It's like feeding a dog on his
own tail. It won't fatten the dog.
- Speech 11/23/1900 Mark Twain

http://heretothereideas.blogspot.com/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20160229/97813821/attachment.html>