Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I would like to know if there is a simple way to backup a failing disk to a larger disk. The failing disk contains my boot partition and hda3 is formatted with XFS. It is 80gb. I have a spare 120gb that I want to copy it to. I found an example that shows how to do it if all file systems are ext2/3, but I have XFS on /de/hda3.
here is the example:
# Mirror hda on hdb
dd if=/dev/hda of=/dev/hdb
# done, the rest of this section assumes that hdb is larger than hda
# Rescan partition tables on hdb
hdparm -Z /dev/hdb
# You must delete the partition and readd it to take up entire disk
# check file system first, assumes ext2/3
# Resize fs to fill partition, again assumes ext2/3
# check fs again
Can someone tell me how to do it if I have an XFS partition?
Below is the disk I want to copy. I couldn't find anything about how to use the full disk after using DD to copy it with XFS.
Disk /dev/hda: 81.9 GB, 81964302336 bytes
255 heads, 63 sectors/track, 9964 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 1 13 104391 83 Linux
/dev/hda2 14 1925 15358140 83 Linux
/dev/hda3 1926 9899 64051155 83 Linux "XFS Partition"
/dev/hda4 9900 9964 522112+ 5 Extended
/dev/hda5 9900 9964 522081 82 Linux swap / Solaris
Do a man on "xfs_growfs" to see if that's what you want.
You could also use "cp -axu <from directory>/* <to directory>". This will copy file by file, of course, and will probably take longer. But, you get the option of making the "to" partition any type you want.
The method uses dd so whatever filing systems, operating systems and the number of partitions doesn't come into the equation if you are only reading the "1" and "0" from a failing disk and write the same information on a bigger disk.
The disk boots exactly like the old one because it is a carbon copy of it.
First : dd is a Bash command you can run in any Linux including one from a Live CD.
Second : dd operates at hardware level and there is no need to mount the drive/partition. dd copies the "1" and "0" only. The clone is a mirror image of your original.
Let me clarify. Since my system is up and running and my objective is to image the disk with the boot partition, root home etc... Can I use dd to image the disk while it is mounted and in use? or will it screw somthing up?
You can run you Linux, watch movie, listen to the MP3 etc while "dd" the whole hard disk in the background.
Like I said it works at the hard ware level and will have no effect on your Linux filing system which is the the ram. In any case your hard disk is for reading purpose so all the mounted partitions will not be screwed up (because nothing is written on them).You may not get everything up to date to the last minute though.
Saikee, the more relevant question is whether the Linux OS is writing changes to the hard drive. If so, then the dd image may be corrupted and could be in a spoiled inconsistent state--possibly without any sort of error warning.
The mere act of running "dd" will at a minimum write to the bash history file. This particular example is unlikely to cause any problems, of course, because by the time "dd" starts doing its work those changes will almost certainly be commited to disk. A more troubling worry is whatever daemons Fedora might have up and running by default. Booting up into single user mode should hopefully avoid any problems.
Personally, I'd boot up into single user mode (if a liveCD isn't an option), and copy the files over manually with "cp -vax" commands. If the source disk is failing, then it's possible that a full "dd" command will fail in the middle. With manual cp commands, it's at least possible to try and copy over bits at a time and get as much as possible.
I must admit I usually use a Live CD to do the cloning job but I had in the past used a Linux from the hard disk too, because I experiencing the dd speed with 32 bit and 64 bit distros. When I started my first dd cloning I couldn't finish a 200Gb disk after 36 hours! The last 500Gb disk I cloned recently took 2.17 hours.
I believe dd does its stuff at a hardware level and the user will only get himself into trouble by unmounting the partitions, while dd is in the middle of working its guts out, thereby forcing the information to be updated into the hard disk, otherwise dd could be quitely happy just cloning the hard disk before changes are implemented into it.
I actually believe dd is more robust than the file copying commands like cp, tar etc because dd copies at least one sector which is the smallest unit. When a file has a dodgy data the whole file may fail in copying whereas dd is almost running at a smooth and constant speed all the time. There are also parameters one can play to tackle the read error in dd plus in Linux one can slow down the DMA to read a disk at a slower speed to improve reliability.
If the disk develops a hardware corruption then eventually no OS can read it. From my experience dd is the last line of defence in disk salvage work.