Debian Sagre Partimage Problem

I have no idea what those error messages mean, or if they are true.

I have no idea about partimage, but it should be possible to do "manually" what partimage does, using fdisk and dd. If partimage is "smart" about not copying blocks that are not in use, dd will take longer time.

I think you need a target parbreastion that is equal size or larger than the source parbreastion, unless you are going to compress the backup. Use "fdisk -ludev-hda" to get a list of parbreastion ondev-hda, and repeat for each disk you are interested in. It's a good idea to print out the output, because, if you delete a parbreastion, you have not yet deleted the data, if you you create a new parbreastion that starts in the same sector and is the same size (or larger) then the data is still there.

If you create new parbreastons on a disk containing the root file system it is likely that fdisk will ask you to reboot afterwards, before doing anything else.

Once the source and destination parbreastions exist, just do

dd if=-dev-sourceparbreastion of=-dev-destparbreastion bs=10M

(The last argument, "bs" is the block size. It's good to have a fairly large block size if you are copying between parbreastions on the same disk, to avoid too much disk head movement. Dd will do a partial block to finish off, if the parbreastion size is not evenly divisible by the block size.

It does not matter if the destination parbreastion is larger. You can still use the destination parbreastion right away, just mount it. It will show in "df" with the size it had in the source parbreastion. You can use "resize2fs" to grow the file system to the size of the parbreastion, in case you simply want to continue using the copy instead of the original.

Just be aware of one small gotcha, if your file systems have labels (parbreastions made by the Linux installation programs generally have labels saying what the intended mount point is), and youretc-fstab has something like "LABEL=-boot" instead of, eg. "-dev-hda3", then after this parbreastion copying exercise, there will be two parbreastions with the same label, and God knows which of them will be mounted.

We just had a thread here in this ng, where a newbie had used konqueror to opendev in a "folder window", and then he clicked on the device file of a parbreastion containing from another distro, (He had two distros on the disk, in different parbreastions. It turned out that some other part of his distro had helpfully entered the parbreastion into the fstab, with the mount point indicated in the label. When this user clicked the device file, Konqueror, also helpfull, mounted the file system. He was running Konqueror as root. Quiz: How did his system behave?

Another point: If you copy from a file system that is mounted and in use, what do you think happens if you try to mount the copy instead of the original? It will behave as when you reboot after a system crash, it will complain that the file system seems not to have been cleanly unmounted. That's no big deal, but consider if you have a database, and you copy the parbreastion while the database is being updated. You will find a corrupt database, and it may be **worse** than after a crash. It may be unable to recover using transaction logs.

If you want to compress, you can do

but dd may give you a better performance by doing larger disk reads and writes. However, I suspect you will be "cpu bound" anyway, with gzip. The problem here is that you don't know the size of the output. If you restore by reversing source and destination, gzip will keep reading garbage beyond the end of the written data. I believe the result will be flawless nevertheless (but don't sue me!), but I would feel better doing something like

and taking note of the the screen output from dd, something like

123456+0 records in 123+4567 records out

meaning there were 123 blocks of 1M and 4567 bytes in a final partial block. If the output size matches the size of the destination parbreastion, it's likely that the parbreastion was too small. (You should get various error messages in this case, though, in addition to the telling numbers. "Broken pipe" from gzip is one of them.)

To restore,

It will still feed gzip with a little too much, since it will make the last block full size.

What I really recommend, though, is to save to a regular file in a file system. In the compressing case, that is. Then the file system keeps track of the size of the file, and I can give the file a sensible name. I have done this myself, I know it works.

If you compress, you may want to first make a file that fills up the the parbreastion, writing zeros to all otherwise free blocks, like this:

mountdev-theparbreastion dd if=-dev-zero of=-some-dir-on-the-partion-lotsazeros rmsome-dir-on-the-partion-lotsazeros

This will make all the unused space compress much better.

Quiz: What happens if you back up to a compressed file inside the *same* parbreastion, as you are reading from?

And what happens when you "restore"??

-Enrique