linux dd question
Hello: I've got a hard disk with a vfat partitition which I'd like to backup using dd. I tried: dd if=/dev/hdc1 of=/mnt/bakup-dd where /dev/hdc1 is the vfat partition and on /mnt is a mounted ext3 partiton. It gave this result: dd: reading `/dev/hdc1': Input/output error 510656+0 records in 510656+0 records out 261455872 bytes (261 MB) copied, 101.931 seconds, 2.6 MB/s What would be the correct dd command to back up the whole vfat partition as a file in an ext3 partition? Thanks, IG _________________________________________________________________ Új érettségi utáni szakképzések térítésmentesen, német nyelvű kiegészítő oklevéllel, ösztöndíjjal! http://ad.adverticum.net/b/cl,1,6022,106048,171567/click.prm
On Monday 21 August 2006 4:30 pm, Istvan Gabor wrote: > Hello: > > I've got a hard disk with a vfat partitition which I'd like to backup > using dd. > I tried: > dd if=/dev/hdc1 of=/mnt/bakup-dd > where /dev/hdc1 is the vfat partition and on /mnt is a mounted > ext3 partiton. > It gave this result: > dd: reading `/dev/hdc1': Input/output error > 510656+0 records in > 510656+0 records out > 261455872 bytes (261 MB) copied, 101.931 seconds, 2.6 MB/s > > What would be the correct dd command to back up the whole > vfat partition as a file in an ext3 partition? Lots of different ways. 1. dd if=/dev/hdc1 of=/dev/hdxn #back up a file system 2. mount /dev/hdc1 /windows/c cd /windows/c rsync -auz . /mnt/windows.backup 3. tar czf /mnt/backup/windows.c.tar.gz . 4. dd if=/dev/hdc1 of=/mnt/bakup-dd/windows.c.img #backup the image of /dev/hdc. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Monday 21 August 2006 21:48, Jerry Feldman wrote:
On Monday 21 August 2006 4:30 pm, Istvan Gabor wrote:
Hello:
I've got a hard disk with a vfat partitition which I'd like to backup using dd. I tried: dd if=/dev/hdc1 of=/mnt/bakup-dd where /dev/hdc1 is the vfat partition and on /mnt is a mounted ext3 partiton. It gave this result: dd: reading `/dev/hdc1': Input/output error 510656+0 records in 510656+0 records out 261455872 bytes (261 MB) copied, 101.931 seconds, 2.6 MB/s
What would be the correct dd command to back up the whole vfat partition as a file in an ext3 partition?
Lots of different ways. 1. dd if=/dev/hdc1 of=/dev/hdxn #back up a file system 2. mount /dev/hdc1 /windows/c cd /windows/c rsync -auz . /mnt/windows.backup 3. tar czf /mnt/backup/windows.c.tar.gz . 4. dd if=/dev/hdc1 of=/mnt/bakup-dd/windows.c.img #backup the image of /dev/hdc.
4 is what he did though. Possibly a problem with the disk? OP: Try monitoring /var/log/messages while running this command and see if there are errors coming up for that disk. You did umount the /dev/hdc didn't you before running this command didn't you? How big is the partition? The speed (2.6 MB/s) makes me suspect a USB pen drive... It may be that because you're not speccing a block and count, and if the partition fills the key, then the I/O error could be due to trying to read the "next" block which is beyond the bounds of the USB pen drive. -- Steve Boddy
4. dd if=/dev/hdc1 of=/mnt/bakup-dd/windows.c.img #backup the image of /dev/hdc.
4 is what he did though. Possibly a problem with the disk? No, what he did was:
On Mon, 21 Aug 2006 23:40:36 +0100 Stephen Boddy <stephen.boddy@btinternet.com> wrote: dd if=/dev/hdc1 of=/mnt/bakup-dd Where bakup-dd is a mounted file system. The difference is that on mine, "of=/mnt/bakup-dd/windows.c.img", windows.c.img is simply a file containing a FAT32 file system image. I don't particularly like this approach because windows.c.img could be huge. In the past, I preferred to simply use a compressed tar archive, but that does not preserve the Windows attributes, but it worked for me in the times when I had to reload a Windows partition. Of course, it also does not preserve the MBR, and that has to point to io.sys or msdos.sys, but I always kept a bootable Windows 9x bootable floppy and ran sys.exe. But, again. I don't use Windows at all any more. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Wednesday 23 August 2006 01:36, Jerry Feldman wrote:
4 is what he did though. Possibly a problem with the disk?
No, what he did was: dd if=/dev/hdc1 of=/mnt/bakup-dd Where bakup-dd is a mounted file system. The difference is that on mine, "of=/mnt/bakup-dd/windows.c.img", windows.c.img is simply a file containing a FAT32 file system image.
Erm, I beg to differ after checking his original post: | dd if=/dev/hdc1 of=/mnt/bakup-dd | where /dev/hdc1 is the vfat partition and on /mnt is a mounted | ext3 partiton. Where he states that "on /mnt is a mounted ext3 partiton", I think his English is possibly a little clunky, but I read that as /mnt is the partition, and bakup-dd is the file. If you read it this way the command is equivalent to yours, he just called his image file "bakup-dd". Slightly unconventional file name for *nix, but perfectly OK. But unless the OP bothers to clarify, we'll hate to agree to disagree. I'll see you on the common at dawn! Swords or Pistols? ;-) -- Steve Boddy
On Wed, 23 Aug 2006 11:29:36 +0100 Stephen Boddy <stephen.boddy@btinternet.com> wrote:
Where he states that "on /mnt is a mounted ext3 partiton", I think his English is possibly a little clunky, but I read that as /mnt is the partition, and bakup-dd is the file. I did not interpret it that way, but I see your point.
If you read it this way the command is equivalent to yours, he just called his image file "bakup-dd". Slightly unconventional file name for *nix, but perfectly OK. I agree. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
ext3 partiton. It gave this result: dd: reading `/dev/hdc1': Input/output error 510656+0 records in 510656+0 records out 261455872 bytes (261 MB) copied, 101.931 seconds, 2.6 MB/s
dd_rescue dd_rescue dd_rescue dd_rescue.
What would be the correct dd command to back up the whole vfat partition as a file in an ext3 partition?
Lots of different ways. 1. dd if=/dev/hdc1 of=/dev/hdxn #back up a file system
Has caveats with some filesystems like XFS.
2. mount /dev/hdc1 /windows/c cd /windows/c rsync -auz . /mnt/windows.backup
Do not use -z when copying locally. Just a waste of cycles. rsync -Pav /windows/c/ /mnt/windows.backup/
3. tar czf /mnt/backup/windows.c.tar.gz .
-czf, czf is error prone. Jan Engelhardt --
On 8/21/06, Istvan Gabor <suseuser04@freemail.hu> wrote:
Hello:
I've got a hard disk with a vfat partitition which I'd like to backup using dd. I tried: dd if=/dev/hdc1 of=/mnt/bakup-dd where /dev/hdc1 is the vfat partition and on /mnt is a mounted ext3 partiton. It gave this result: dd: reading `/dev/hdc1': Input/output error 510656+0 records in 510656+0 records out 261455872 bytes (261 MB) copied, 101.931 seconds, 2.6 MB/s
What would be the correct dd command to back up the whole vfat partition as a file in an ext3 partition?
Thanks, IG
Istvan, Someone else mentioned dd_rescue, but more often than not, that is overkill. You just need to use a dd command that is more tolerant of the occasional disk i/o error. (i'm assuming you don't have hundreds of thousands of them). I use: dd if=/dev/hdc1 of=/mnt/bakup-dd bs=4k conv=noerror,sync bs=4k is purely a speed issue. I don't remember the details, but if you don't use it, dd will sometimes take 10x or more longer than if you do use it. Has to do with kernel buffering. conv=noerror,sync is the critical piece for you. noerror says that if there is an error continue performing the dd (ie. don't error out like your command did). sync says if there is an error fill in the unreadable block with nulls. Unfortunately, the default is just to ignore the input block with the read error, so if you don't use sync, each disk error causes the backup file to be shorter by a block. But the missing data is not from the end, it is right out of the middle. If you ever had to restore that backup, you would have nothing but garbage after the missing block. HTH Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
participants (5)
-
Greg Freemyer -
Istvan Gabor -
Jan Engelhardt -
Jerry Feldman -
Stephen Boddy