[lug] fork from network drives as backup

Bear Giles bgiles at coyotesong.com
Thu Jul 27 10:52:30 MDT 2006

Sean Reifschneider wrote:

>On Wed, Jul 26, 2006 at 08:29:28PM -0600, D. Stimits wrote:
>>But...I've never really run into the concept of using bare metal 
>>restores of existing installs via backup. What does it take? Just 
>>something like amanda running on a backup server with a NIC and services 
>>like NFS/bootp/dhcp? Or does this depend on the distribution of linux?
>One of the ideas I've wanted to implement, but haven't had time, is to
>cooperate with the system package database for backing things up.
>Walk the file-system and check them against the package database.  If the
>file is an unmodified copy of something provided by the system packages,
>ignore it.  Otherwise, save it.  You'd also need to save a list of packages
>on the system.
I was looking at a variant of that. I added the thought that the package 
database would -own- /bin/, /sbin, /usr/bin, /usr/lib, etc. Any file 
that wasn't listed in the package database(*) would be flagged as suspect.

Locally installed applications would go under /opt, as Kernigan & Pike 

(*) When I say 'package database', I don't just mean the files under 
/var/lib/dpkg. I know how to rip apart .deb files so I can capture the 
ownership, permissions and cryptographic hashes of all of the installed 
files. It's just a tarball within a 'ar' file, after all.

>Then, recovery would just involve doing a re-install from the normal
>channels, making sure the same set of packages was installed, and then
>de-archive all the files that were saved.
Two problems. The first is simply getting the same packages -- mirrors 
don't always retain the older packages, esp. if there have been security 
releases in the interrim.

The second is more subtle. Package installers expect to install 
packages. Not just write the files to disk. You can probably just us an 
'unpack' option, but if not you'll need to rip apart the packages yourself.


More information about the LUG mailing list