-
04-19-2010, 11:49 AM
#151
You are certainly welcome to my address
-
04-19-2010, 05:54 PM
#152
Kavi,
You can either open a new thread or PM me. If the information is useful to others then a thread can serve as a record.
-
12-17-2010, 03:06 AM
#153
It seems I am resurrecting a somewhat old thread with my first post. First, thanks saikee for all of the information you've given in both this thread and the original "Using Linux Live CD to clone XP" one. I've gone through all the pages of both topics now.
I am hoping to back up an XP installation to an external USB HDD, but since I already have files on it, I guess I have to use the method of mounting the USB drive and using dd to write an image of the disk. In the original topic, you quoted a post claiming that you could do it this way:
Code:
dd if=/dev/sdb2 ibs=4096 | gzip > partition.image.gz
However, for restoring the backup, you only copied:
which I would assume was only part of the original command. I have also been told that it would be possible to perform the backup this way:
Code:
dd if=/dev/sda | gzip -c - > /path/to/usb/drive/hdd-backup.gz
and that restoration could be performed this way:
Code:
gunzip -c /path/to/usb/drive/hdd-backup.gz | dd of=/dev/sda
Have you ever tried doing backups to disk images rather than your usual raw disk-to-disk method? Is the chance of failure or having XP "reject" the backup once it has been restored to another HDD higher if you use a disk image? If so, I may just deal with the expense of buying yet another HDD so I can do a raw backup the way you recommend. I know that backing up to an image prevents you from restoring individual files from the backup, but depending on how large the disk image is, I may actually be able to fit two copies of the HDD contents on my backup drive -- a full disk image created in this method, and a plain copy-paste of the files made from within Windows that I can use to restore individual files if necessary. It may be an inefficient use of space, but at least it could save me the expense of buying another drive at present.
Also, I noticed a few comments about USB drives and power -- my drive only connects to a single USB port, not two. Does that increase the chance of write failures during the backup process, or something to that end? I got that impression from reading older posts.
Sorry for all the questions at once, and thanks for any help you can provide.
-
12-17-2010, 06:48 PM
#154
AleronIves,
Welcome to Justlinux!
It is true that I favour the disk to disk cloning because you save time in compressing and decompressing the file. In a disk cloning you can use the clone, extract data from it freely or swap it to boot as the original. It is bomb proof because the clone is a mirror image of the source and I have never had a sinle failure with this method.
I have done backups of a hard disk to a file but that was for small capacities. It is only a matter of manipulating the output file into an input file.
If your are cloning the whole disk, as some of your questions refer to it, then cloning the whole disk is a a lot safer. All you need to make sure is the number of cylinders partitioned in the source disk can be accommodated in the target disk. Thus you can clone a 2TB hard disk into a 0.5TB disk if you can temporarily shrink the partitions used below 0.5TB.
The power of cloning the whole disk is when the first sector, which is the MBR, is cloned your target disk must have the same partition table as the source. Therefore you do not need to pre-partition the target disk, any spare will do or a raw disk direct from a new purchase. By default all the data inside the target will be overwritten.
The laptop 2.5" hard disk usually consumes more than 0.5Amp which is the limit of a standard USB port. Thus you need to have a twin head USB cable to pull 1Amp current. I have not come across a 2.5" laptop disk that use over 1 Amp and have seen only small capacity laptop disks with say only 10Gb that consumes less than 0.5 Amp. The consumption is stamped on every hard disk.
The desktop 3.5" hard disk has its own power supply as it need both 12DVC and 5VDC.
-
12-17-2010, 08:08 PM
#155
Thanks for the reply. If you use dd to dump the entire disk to a file, and then you use dd to dump that file to an unformatted raw disk, wouldn't that yield the same result as using dd to dump the entire disk 1 directly into disk 2, as per your method? Since I don't have a second blank HDD right now, using the intermediate step of dumping to a file would be helpful, but only if it does yield the same end result as your method. I'm not sure why it wouldn't, so I would be grateful for any clarification you could provide. If going to a file does work, were the dd examples that I posted earlier valid for doing that?
-
12-18-2010, 04:40 PM
#156
leronIves,
The end result should be the same whether you do it from disk-to-disk or disk-to-file-to-disk.
Back up a large disk is a time consuming exercise and the speed can be optimised using the block size. This is easily done with a hard disk but I am not sure how flexible it is with a file. dd copies one sector of 512 bytes by default unless the user overrides it with "bs=XXXXX" where xxxx is the block size in bytes. The number of records times the block size is the exact size of the data transferred.
I suggest bs=32256 which is 63 sectors x 512 byes per sector. This is one complete track. If the bs parameter is missing the same track is read/write 63 time.
I guess with a file one might have to write down the number of the records and block sizes to keep track of the exact size of the data whereas with a disk the information is automatically inside the partition table.
If you are noe already aware in using dd a hard disk you must destroy everything in the target disk because the first sector of the back up is the MBR making the target disk having the exact partition table as the original. This is to say if you back up a Xp disk from a 80Gb hard disk. The image will be fixed at 80Gb even you restore it on a 2TB hard disk. The balance will be only unallocated empty space with which you can use Gparted to resize the partition after restoration.
If the image goes back to the original hard disk then everything will fit exactly.
I must say I do favour the disk to disk arrangement because in this arrangement I will have the original hard disk untouched. If the cloned image for some reason become defective, say from a corrupt hard disk, I still have the original disk to go back to.
Put the hard disk image on a file is fine but there is no way of telling the image is perfect. If the image does not work but restored onto the original disk then I would lose the entre operating system.
The normal way I woiuld do it is to get hold of a spare disk and clone the hard disk across. I would then remove the original disk for safe keeping and use the clone straight away.
-
12-21-2010, 03:09 AM
#157
Another reason I want to copy to an image is to be able to compress the free space, but I've found that there aren't that many reputable applications to zero free space on Windows. At this point, SDelete looks like the best option to me. I can't use Eraser, since I only have XP SP2, and it apparently requires SP3. Unless you have experience with a better tool, I guess I'll try SDelete's -c option and hope it does the trick. It's too bad something simple like cat /dev/zero > file doesn't seem to be available, unless someone has ported it to Windows. Though newer Linux versions reportedly can write to NTFS filesystems, it seems safer to try to zero the free space from within Windows.
*edit*
SDelete works.
Last edited by AleronIves; 12-22-2010 at 12:55 AM.
-
01-12-2011, 11:09 PM
#158
Thank you so much for sharing such wonderful information that was posted here. Thank you for sharing.
-
01-13-2011, 01:38 PM
#159
deanaossenfo,
Welcome to Justlinux!
I am merely passing the knowledge the members of this forum have taught me in the past.
-
02-10-2011, 03:58 PM
#160
Win XP doesn't work properly after cloning
I'm attempting to clone a drive with a functioning dual boot Win XP/Linux to a larger one using the dd command. However, the cloned Windows OS doesn't work properly, although the Kubuntu that resides on a separate partition on the same drive does.
The cloned drive slowly boots into Windows, but when I log in to Administrator, the task bar is missing, although I can navigate using Explorer because there are shortcuts on the desktop. None of the user accounts are accessible, neither from the login screen (they are there, but when I click on them they won't load) or from within the Control Panel in Administrator mode.
I'm not so much asking how to fix these problems from within Windows as trying to figure out what I'm doing wrong. I've tried the cloning process twice with the same results. I then wrote zeros to the drive and tried again with the same results. I then tried to clone onto a different HDD, but the results were also similar.
FWIW, GParted reports that the source disk has one or more bad sectors, so I used the following command to clone the disk:
Code:
sudo dd if=/dev/sda of=/dev/sdb conv=noerror,sync
In a couple of cases GParted reported errors on the cloned disk, but in the latest attempt it did not.
Any suggestions would be appreciated.
Harry
-
02-10-2011, 05:16 PM
#161
HarryB,
Welcome to Justlinux!
For a Xp the necessary condition is to remove the source when booting up the clone in exactly the same position.
If the source has bad sectors then the bad sectors cannot be read and so the cloned disk can have holes or blank spots in eexactly the same locations as the source. Technically the clone should have no choice but to behave exactly as the source.
Thus my guess is you can clone your Xp but the source is probably doing the same thing. Cloning doesn't get rid of the bad sectors. What you do get is in the clone is that it is healthy and all sectors can be read and written whereas a bad disk will continue to decline until it is unreadable.
Once a disk develops bad sectors the condition can deteriorate very quickly. Thus it pays to limit its spinning time and have it clone ASAP.
-
02-10-2011, 11:12 PM
#162
![Quote](images/misc/quote_icon.png) Originally Posted by saikee
HarryB,
Welcome to Justlinux!
Thank you!
For a Xp the necessary condition is to remove the source when booting up the clone in exactly the same position.
I removed the source disk before booting from the target one, which was placed in the same location on the cable as the source.
If the source has bad sectors then the bad sectors cannot be read and so the cloned disk can have holes or blank spots in eexactly the same locations as the source. Technically the clone should have no choice but to behave exactly as the source. Thus my guess is you can clone your Xp but the source is probably doing the same thing.
The OS on the source disk has been running smoothly for quite some time - I have had no problems with it (other than the occasional ones after automatic updates). The "cloned" OS operates entirely differently, booting into Windows, but misbehaving after it gets to the log-in screen. It is unusable.
Cloning doesn't get rid of the bad sectors. What you do get is in the clone is that it is healthy and all sectors can be read and written whereas a bad disk will continue to decline until it is unreadable.
Apparently the data in the bad sector(s) is not being used by Windows on the source disk because it is running smoothly.
Once a disk develops bad sectors the condition can deteriorate very quickly. Thus it pays to limit its spinning time and have it clone ASAP.
I was unaware there were any problems on the source disk until I ran GParted and it reported one or more bad sectors. The reason I decided to clone the disk is because it is running out of free space.
Something I don't understand is going on - and it is repeatable. I have now done 4 or 5 "clonings", each in a slightly different manner, and the results have been similar each time.
-
02-12-2011, 12:44 PM
#163
Can you post here the output of , say before and after the cloning?
Technically dd reads from the source disk a number of sectors specified by the user and writes on the target disk. Since the first sector is the MBR so the target disk is "forced" to have the same partition table as the source.
The read/write head must read one sector complete in eachoperation and the information transferred is just the binary pattern. Therefore the target is a mirror image of the source and there cannot be anything else. No filing system is involved. dd only stops when either the number of sector has been exhausted in either the source or the target disk.
Can you repeat the process without the "sync" option?
-
02-13-2011, 11:44 PM
#164
![Quote](images/misc/quote_icon.png) Originally Posted by saikee
Can you post here the output of , say before and after the cloning?
I'm not sure what you mean by "before cloning". I used GParted to delete the partitions on the malfunctioning target disk before attempting to clone again. (I now realize that dd over writes the partition table, so deleting the partitions isn't necessary.)
[snip]
Can you repeat the process without the "sync" option?
Here is the output of the dd command without the "conv=noerror,sync" option, plus the fdisk result:
Code:
ubuntu@ubuntu:~$ sudo dd if=/dev/sda of=/dev/sdb
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 504.96 s, 6.3 MB/s
ubuntu@ubuntu:~$
------------------------------------------
ubuntu@ubuntu:~$ sudo fdisk -l
Disk /dev/sda: 13.0 GB, 13030907904 bytes
255 heads, 63 sectors/track, 1584 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x6c716c71
Device Boot Start End Blocks Id System
/dev/sda1 * 1 1097 8811621 7 HPFS/NTFS
/dev/sda2 1098 1219 979965 82 Linux swap / Solaris
/dev/sda3 1220 1584 2931862+ 83 Linux
Disk /dev/sdb: 41.1 GB, 41110142976 bytes
255 heads, 63 sectors/track, 4998 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x6c716c71
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1097 8811621 7 HPFS/NTFS
/dev/sdb2 1098 1219 979965 82 Linux swap / Solaris
/dev/sdb3 1220 1584 2931862+ 83 Linux
ubuntu@ubuntu:~$
And here is the output without the "sync" option plus the fdisk result:
Code:
ubuntu@ubuntu:~$ sudo dd if=/dev/sda of=/dev/sdb conv=noerror
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 491.442 s, 6.4 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 514.366 s, 6.2 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 537.297 s, 5.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 560.217 s, 5.7 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 583.125 s, 5.4 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 606.077 s, 5.2 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 628.989 s, 5.0 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.917 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.942 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.942 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.942 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.943 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.943 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.943 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.943 s, 4.9 MB/s
dd: reading `/dev/sda': Input/output error
6190552+0 records in
6190552+0 records out
3169562624 bytes (3.2 GB) copied, 651.943 s, 4.9 MB/s
25450976+0 records in
25450976+0 records out
13030899712 bytes (13 GB) copied, 2755.61 s, 4.7 MB/s
ubuntu@ubuntu:~$
-------------------------------------------
ubuntu@ubuntu:~$ sudo fdisk -l
Disk /dev/sda: 13.0 GB, 13030907904 bytes
255 heads, 63 sectors/track, 1584 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x6c716c71
Device Boot Start End Blocks Id System
/dev/sda1 * 1 1097 8811621 7 HPFS/NTFS
/dev/sda2 1098 1219 979965 82 Linux swap / Solaris
/dev/sda3 1220 1584 2931862+ 83 Linux
Disk /dev/sdb: 41.1 GB, 41110142976 bytes
255 heads, 63 sectors/track, 4998 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x6c716c71
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 1097 8811621 7 HPFS/NTFS
/dev/sdb2 1098 1219 979965 82 Linux swap / Solaris
/dev/sdb3 1220 1584 2931862+ 83 Linux
ubuntu@ubuntu:~$
Both of these methods produced the same results: when I tried to mount the Windows partition on the target disk I received an error message, the first part of which read: $MFT must be non-resident. Failed to load $MFT: Input/output error Failed to mount '/dev/sdb1': Input/output error NTFS is either inconsistent, or you have hardware faults ...
I have no idea if any of this is helpful, but I will note that I have attempted to clone the source disk using HDClone, a free (many features disabled) Windows program onto a different drive. Although I haven't yet had the chance to really test it, I have reason to think that clone was successful.
Last edited by HarryB; 02-14-2011 at 07:39 AM.
-
02-14-2011, 01:48 PM
#165
Your cloning with dd has failed in both cases.
Your source is 13Gb large and the target is 41.1Gb so a standard cloning will stop once the source is exhausted in reading.
However dd reported only
6190552+0 records in
6190552+0 records out
were processed. As the block was not specified so the default of 1 record= 512 byte would be used. 512 bytes times 6190552 is 3.17Gb. Therefore only part of the source was successfully cloned and the rest was missing.
Although the partition table is identical in both disks that is only because it came out from the first 512 bytes of sda and sdb.
My guess is you are using only partly cloned disk with the remaining 13-3.17=9.83Gb same as before. Thus that explains the funny behaviour of the Xp.
If you destroy the partition table you only clear the 64 bytes in the first 512 bytes (called the MBR). The information of the partition interior is untouched! Therefore even the target was partly cloned with 3.1Gb its remainder could still be usable.
dd in your case has clearly stated that there was an input/output error in sda causing it to terminates itself prematurely.
Your sda hard disk has deteriorated to the extent that dd cannot read the entire disk in each attempt.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|