In a previous job, I worked with windows-based software under active
development with the result that all programmers were recommended to
prepare and keep available a "disk image". The idea was that you'd set
up a test machine such that it was comfortable, had the development
and debugging software you needed installed, and then backup the
partition bit-by-bit. If the latest build left the machine in a
confused state - perhaps the registry was polluted - it was simple to
restore the image and try again with the next build. It was a brute
force solution, but disk space is relatively cheap, and it meant we
didn't have to worry about whether or not file attributes, ACLs,
owners and so on were preserved by the backup software.
I wanted a linux solution, so put together a couple of
simple perl programs to do the job. I see now from a previous post
that partimage may do mostly the same thing and a whole lot more, but
maybe these will be useful to someone. Each script takes as an
argument a block device and a directory, and either backups up the
block device to a collection of files in the given directory, or
restores from that directory. In addition, when backing-up, an MD5
checksum is generated and stored for each chunk of partition read. My
idea was that the restore program would only restore "blocks" for
which the MD5 checksum generated from the current disk contents didn't
match the checksum for the backed-up "blocks". Of course the program
has to read the disk on restore to generate the current MD5 contents,
but I speculated it might still come out faster if the disk content
was relatively unchanged from the previous restore, which was often
the situation I faced (all that changed was the result of installing
the latest build, for instance).
I've used it dozens of time successfully; but there's no warranty. I
don't know how efficient it is; it seems to me that relatively little
time is spent doing IO, which must be a bad sign. I never looked into
it further though. I planned to add support for incremental backups
too - i.e. store in a directory backup2 only backups of the blocks that
differ from those in backup1 - so providing an easy way to have
several disk images that share common disk blocks (e.g. one base
install, another with Visual Studio, etc.) It should be easy to
do. Anyway, these files are in the public domain.
Slashdot Mirror
I wanted a linux solution, so put together a couple of simple perl programs to do the job. I see now from a previous post that partimage may do mostly the same thing and a whole lot more, but maybe these will be useful to someone. Each script takes as an argument a block device and a directory, and either backups up the block device to a collection of files in the given directory, or restores from that directory. In addition, when backing-up, an MD5 checksum is generated and stored for each chunk of partition read. My idea was that the restore program would only restore "blocks" for which the MD5 checksum generated from the current disk contents didn't match the checksum for the backed-up "blocks". Of course the program has to read the disk on restore to generate the current MD5 contents, but I speculated it might still come out faster if the disk content was relatively unchanged from the previous restore, which was often the situation I faced (all that changed was the result of installing the latest build, for instance).
I've used it dozens of time successfully; but there's no warranty. I don't know how efficient it is; it seems to me that relatively little time is spent doing IO, which must be a bad sign. I never looked into it further though. I planned to add support for incremental backups too - i.e. store in a directory backup2 only backups of the blocks that differ from those in backup1 - so providing an easy way to have several disk images that share common disk blocks (e.g. one base install, another with Visual Studio, etc.) It should be easy to do. Anyway, these files are in the public domain.