<html><head></head><body><div>On Mon, 2016-02-29 at 15:52 -0500, Derek Atkins wrote:</div><blockquote type="cite"><pre>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
<blockquote type="cite">
sort > /root/package-list" when the backup begins (or perhaps at a daily
</blockquote>
cron job)? Or do you do something... different?
</pre></blockquote><div><br></div><div>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.</div><blockquote type="cite"><pre>
Do you exclude e.g. the RPM (or apt) package directory/database? Or do
you exclude all of /var/lib?
</pre></blockquote><div>No. A disaster restore is a fresh install plus recovery of config files and user/system data. Let rpm "do it's thing".</div><blockquote type="cite"><pre>
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?
</pre></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><blockquote type="cite"><pre>
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:
<blockquote type="cite">
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:
<blockquote type="cite">
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
</blockquote>
--
Got Linux? Used on smartphones, tablets, desktop computers, media
centers, and servers by kids, Moms, Dads, grandparents and IT
professionals.
_______________________________________________
Ale mailing list
<a href="mailto:Ale@ale.org">Ale@ale.org</a>
<a href="http://mail.ale.org/mailman/listinfo/ale">http://mail.ale.org/mailman/listinfo/ale</a>
See JOBS, ANNOUNCE and SCHOOLS lists at
<a href="http://mail.ale.org/mailman/listinfo">http://mail.ale.org/mailman/listinfo</a>
</blockquote>
</pre></blockquote><div><span><pre>--
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/
</pre></span></div></body></html>