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

[Jim Kinney]

On Mon, 2016-02-29 at 16:43 -0500, Derek Atkins wrote:
> Hi Jim,
> 
> On Mon, February 29, 2016 4:19 pm, Jim Kinney wrote:
> > 
> > On Mon, 2016-02-29 at 15:52 -0500, Derek Atkins wrote:
> > 
> > > 
> > > 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 kick the rpm dump from the backup or just a cron job?  I suppose
> the package list isn't really modified frequently, so worst case you're
> off by a day (if you care about specific versions).
> 

Either works. You can also backup /var/log/yum.log and get the update
history as well.
> > 
> > > 
> > > 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".
> > 

> 
> 
> Sure, what what constitutes "user/system data"?  For example, if you're
> running a web server, wouldn't you back up /var/www ?  Or for a mail
> server, wouldn't you backup the mail spools?
> 
> Obviously MySQL is a bit more of a trick, most likely you do need to run a
> mysqldump as part of the backup process.
> 
> I'm not sure if there is anything special I would need to do to backup a
> cyrus DB.
> 

All of those are "system data". Maybe service data would be a better
name. Basically, if a machine runs a service that generates or stores
files of any type, back up that area.
Databases require special care and feeding. Some are small enough that
a dump is sufficient. Others are too large for that and you have to use
DB-specific methods/tools to backup them up live. There's a point above
which backups are not feasible and you have to rely on drive arrays and
data redundancy. 
> > 
> > > 
> > > 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.
> > 

> 
> 
> I'm more thinking something like "vmware", or possibly user-installed
> "scripts" that got installed into /bin.  Although I suppose in that latter
> case there is a source file elsewhere that did get "installed", so just
> backing up the source (/root) is sufficient.
> 

I only let users install in their home dir. I only install custom
scripts in /usr/local. As much as possible, I want /bin, /usr/bin,
/sbin, /usr/sbin to be installed from a a DVD and/or updated packages
with SHA sums and managed by rpm/yum/dnf.
> In summary so far, it sounds like one should backup:
> 
> /etc
> /root
> /home
> parts of /var (but not all of /var)
> and then extra work for certain server state (e.g. mysqldump).
> 
> Am I missing anything?
> 

/usr/local is where locally compiled stuff should be installed.
Ideally, it should also be it's own partition.
> Thanks, all!!
> 
> -derek
> 
> 

-- 
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/17c5cef5/attachment.html>