dd command

[satimis]

Hi folks,

I have a new HD configured with 7 partitions as follows;

/dev/hda1 boot ext2
/dev/hda2 sawp
/dev/hda3 ext3
/dev/hda5 ext3
/dev/hda6 ext3
/dev/hda7 ext3
/dev/hda8 ext3

I ran LFS LiveCD to do the job. OS not yet installed. /dev/hda8 has about 1.2G data.

Later /dev/hda8 enountered mounting problem. I backup its data to /dev/hda7 by running;
# dd if=/dev/hda8 bs=1M | gzip -c - > /mnt/hda7/partition.image.gz

After fixing the problem by running;
# fcsk.ext3 -b 32768 /dev/hda8

I restored the image file to /dev/hda6 to check whether backup did work with following steps;

# mount -t ext3 /dev/hda7 /mnt/hda7
# cd /mnt/hda7
# gunzip -d partition.image.gz | dd bs=1M of=/dev/hda6
gunzip: partition.image: No space left on device
in 0+0
out 0+0
0 bytes transferred in 221.150830 seconds (0 bytes/sec)

# df -hT /mnt/hda6
Filesystem Type size used avail use%
/dev/hda6 ext3 7.4G 33M 7.0G 1% /mnt/hda6
partition /hda6 has 7G available space

# du -h /mnt/hda7/partition.image.gz
2.0G /mnt/hda7/partition.image.gz
The image size is only 2G

# df -hT /mnt/hda8
Filesystem Type size used avail use%
/dev/hda8 ext3 4.9G 1.2G 3.5G 25% /mnt/hda8
The size of original data is only 1.2G

My questions are
1) Why the size of the image is bigger than that of the original data on /dev/hda8?
2) Whether the backup command was wrong, creating a defective image?
3) Or whether the image created including the problem on /dev/hda8 ?
4) Whether the restore command was wrong

Please advise. TIA

B.R.
satimis

[zeroth404]

Hi folks,

I have a new HD configured with 7 partitions as follows;

/dev/hda1 boot ext2
/dev/hda2 sawp
/dev/hda3 ext3
/dev/hda5 ext3
/dev/hda6 ext3
/dev/hda7 ext3
/dev/hda8 ext3

I ran LFS LiveCD to do the job. OS not yet installed. /dev/hda8 has about 1.2G data.

Later /dev/hda8 enountered mounting problem. I backup its data to /dev/hda7 by running;
# dd if=/dev/hda8 bs=1M | gzip -c - > /mnt/hda7/partition.image.gz

After fixing the problem by running;
# fcsk.ext3 -b 32768 /dev/hda8

I restored the image file to /dev/hda6 to check whether backup did work with following steps;

# mount -t ext3 /dev/hda7 /mnt/hda7
# cd /mnt/hda7
# gunzip -d partition.image.gz | dd bs=1M of=/dev/hda6
gunzip: partition.image: No space left on device
in 0+0
out 0+0
0 bytes transferred in 221.150830 seconds (0 bytes/sec)

# df -hT /mnt/hda6
Filesystem Type size used avail use%
/dev/hda6 ext3 7.4G 33M 7.0G 1% /mnt/hda6
partition /hda6 has 7G available space

# du -h /mnt/hda7/partition.image.gz
2.0G /mnt/hda7/partition.image.gz
The image size is only 2G

# df -hT /mnt/hda8
Filesystem Type size used avail use%
/dev/hda8 ext3 4.9G 1.2G 3.5G 25% /mnt/hda8
The size of original data is only 1.2G

My questions are
1) Why the size of the image is bigger than that of the original data on /dev/hda8?
2) Whether the backup command was wrong, creating a defective image?
3) Or whether the image created including the problem on /dev/hda8 ?
4) Whether the restore command was wrong

Please advise. TIA

B.R.
satimis

thats som crazy stuff you got going there. quite a mess

if I were you, I'd reformat the whole shebang and restore my files from backup. You do have backups, don't you?

[satimis]

Hi zeroth404

You do have backups, don't you?

Sorry, I don't have.

This is a new HD without OS. I used Knoppix to run this box. After having files copied onto a partition from several CDs (all data) and rearranged them therefore, it went wrong. Now I have fixed the problem of the partition and all data found there.

My purpose to restore the image file was solely to check whether the dd command applied both on creating the backup and restoring the latter to another partition were correct. The data on the image file created is not important to me.

B.R.
satimis

[oneandoneis2]

That looks quite a weird way of doing it. . . dd isn't the best tool for backing up a drive: It doesn't distinguish between files & empty space. . .

Anyway, I think the "no space" error is deceptive - the error message states no data was written or read.

In particular, I don't think your command was actually making the unzipped gzip file an input for dd. Surely you'd have to unzip the file using "-dc" to get the output redirected to stdout?

[scm]

That looks quite a weird way of doing it. . . dd isn't the best tool for backing up a drive: It doesn't distinguish between files & empty space. . .

Anyway, I think the "no space" error is deceptive - the error message states no data was written or read.

In particular, I don't think your command was actually making the unzipped gzip file an input for dd. Surely you'd have to unzip the file using "-dc" to get the output redirected to stdout?

The mistake you made was giving gunzip the file name so it'll perform the unzip in situ. This means that you'll need enough space in your current directory for both the zipped and unzipped files! Try

gunzip <partition.image.gz | dd bs=1M of=/dev/hda6

[satimis]

Hi oneandoneis2,

. . . dd isn't the best tool for backing up a drive: It doesn't distinguish between files & empty space. . .

Agreed. Usually I either burn the data direct on CDs OR create a tarball first and then burn the same on CD. At the time when the partition went into problem failing to be mounted I could not think of other tools to rescue the data so I ran dd.

I don't think your command was actually making the unzipped gzip file an input for dd. Surely you'd have to unzip the file using "-dc" to get the output redirected to stdout?

Whether you suggested to run

# gunzip -dc partition.image.gz | dd bs=1M of=/dev/hda6

I'll test it later. I'm now anwsering the forum on another PC.

Tks.

satimis

[satimis]

Hi scm,

This means that you'll need enough space in your current directory for both the zipped and unzipped files!

Whether you meant to copy the zip file to a partition where having sufficient space to unzip it.

I can't test it now. I'm answering the posting on another PC on another location.

B.R.
satimis