[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Backup package initial target



Notwithstanding my just-mailed and likely to be modified set of
requirements for backup, I am going to list here the goals for
the first version of backup which might be useful.  This is so
that we have something to use and perhaps form opinions about
required functionality for backup.

Re-installation will require that the base system and the backup
package be manually reinstalled.  The Debian packages needed
should be made available in the directory /Debian/backup.  (This
could be a symbolic link to an NFS-mounted directory.)


Backup script:
o)	This will be a simple (probably shell) script.
o)	A list of files unique to this system will be generated
	by taking the difference between the list of all files
	on the system and the list of files installed by dpkg,
	and adding in all configuration files listed in the dpkg
	status file.  The files under /var/lib/dpkg will not be
	included in the list.
o)	The files in the list established above will be copied
	into an archive (probably using cpio).
o)	The archive will be compressed (probably using gzip).
o)	A list of packages (with version numbers) will be
	generated and written to a file.
o)	The file containing the list of packages and the
	compressed archive will be written to diskettes
	(probably using ``tar -M'').


Restore script:
o)	This will be a simple (probably shell) script.
o)	The file containing the list of packages will be read
	off of the backup media.  (The real trick here, is to
	stop reading the tar disk as soon as the list of
	packages is read.)
o)	The listed packages will be selected for installation
	and ``dpkg --unpack --auto /Debian/backup'' will be used
	to install the packages.
o)	Read in the tar image, pass that through ``gzip -dc''
	and cpio to install the files unique to this system.
o)	Modify the dpkg status file to make it look like the
	packages are properly installed.


Unfinished business:
o)	It would be really good if there were some way to
	separate out the postinst processing which is
	interactive from that which is not.  Would it be too
	much to ask that package maintainers make their
	postinst scripts ``backup aware'' by making them
	accept a ``--backup'' or ``--restore'' argument?
	(This needs discussion.)


-- 
   David H. Silber     dhs@firefly.com     Project:  Debian GNU/Linux (uucp)
   <http://www.access.digex.net/~dhs/>     Wanted:  Spare time.


Reply to: