On Jun 7, 2009, at 12:34 PM, Les Mikesell wrote: > Niki Kovacs wrote: >> Hi, >> >> I'm currently experimenting with G4U (Ghost for Unix), a small >> cloning >> application sending disk images to an FTP server. >> >> The application reads the whole disk bit by bit, compresses it and >> then >> stores it remotely. Due to this approach, it's more or less >> filesystem-independent. The drawback is that it sometimes results in >> huge image files. >> >> Now I'm currently following a hint which suggests to fill the disks' >> unused space with zero bits. Here's the command for that: >> >> # dd if=/dev/zero of=/0bits bs=20M >> # rm /0bits >> >> Now I gave that a shot, but after half an hour or so, I got a bit >> impatient. Now the computer does not respond any more. Does that mean >> he's just way too busy with dd? Or is there some mistake in the >> command? >> As I see it, it will just be chugging on and on, no? Shouldn't >> there be >> a 'count=x' option somewhere? > > I'll second the recommendation for clonezilla. It knows enough about > most filesystems (including windows ntfs) to only store the used > blocks > and it can use network storage over nfs, smb, or sshfs if you use the > bootable CD clonezilla-live version. If you do a lot of cloning, you > can also use the network-booting drbl version on a server that will > PXE > boot a client into clonezilla with the image storage directory already > NFS-mounted. There is an rpm for Centos to install this. The problem I had with clonezilla I had when I tried it once was I was attempting to clone a hard drive (windows) that had some bad sectors. Clonezilla didn't handle that well at all. Either in duplicating the drive from one drive to another, or when I tried to back it up to a file on another USB drive failed verify. Luckily, I had done a recent windows backup, so I went through the recovery DVD route on the new drive, removed programs I had previously removed from the factory install, then restored over itself. I spent a lot of effort trying to avoid that.