First, I am not a RedHat or linux newbie. I simply have not had to do what I am getting ready to do, and I want to see if I am going to run into a problems...
My HDA drive is failing (I can hear the occasional click from it and I am seeing Smart errors, the transfer rate is slow but all my data is there).
I have 3 partitions on it, the /, /boot/ and my game servers (this is also the drive the bootloader is on).
Will this proceedure work ok to replace it with the minimum of downtime/reinstalling
A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit!
Any hangups or snags doing it this way?
Thanks, Doug Eubanks doug@simflex.com
A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit!
well if you want a real quick'n'dirty way to do it then you can simply turn off the computer, hook up the drive, boot with kernel command line init=/bin/bash, watch the messages for info on what device name the new drive got and do "/bin/dd if=/dev/hd{source} of=/dev/hd{target} bs=1048576", once it completes do "/bin/sync" and powerdown, remove the old disk and hook up the new disk in it's place and reboot and usually everything works normally. [it does screw up drive geometry but since linux uses LBA adressing anyway this is irrelevant]
if there are read errors on the source drive you'll probably want to use dd_rescue instead of dd.
use G4U to clone it to an ftp server or second drive
much easier
Maciej Z.enczykowski wrote:
A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit!
well if you want a real quick'n'dirty way to do it then you can simply turn off the computer, hook up the drive, boot with kernel command line init=/bin/bash, watch the messages for info on what device name the new drive got and do "/bin/dd if=/dev/hd{source} of=/dev/hd{target} bs=1048576", once it completes do "/bin/sync" and powerdown, remove the old disk and hook up the new disk in it's place and reboot and usually everything works normally. [it does screw up drive geometry but since linux uses LBA adressing anyway this is irrelevant]
if there are read errors on the source drive you'll probably want to use dd_rescue instead of dd.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Okey, picking the one I think is the least likely to lead to a flamewar (except regarding top-posting :)).
On Sun, Jun 12, 2005 at 12:10:52AM +0100, Peter Farrow wrote:
use G4U to clone it to an ftp server or second drive
much easier
I have not checked G4U yet, so I really mean this as a question:
How is it easier ? dump | restore is as straightfoward as it gets. I have been using it for 15+ years, and never had a problem (except for raiserfs filesystems, of course).
Yes, if I were going to produce a lot of copies of the same disk, then I would look for something like Ghost (or G4U, will check it later tonight). But for this particular task ?
Maciej Z.enczykowski wrote:
A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit!
well if you want a real quick'n'dirty way to do it then you can simply turn off the computer, hook up the drive, boot with kernel command line init=/bin/bash, watch the messages for info on what device name the new drive got and do "/bin/dd if=/dev/hd{source} of=/dev/hd{target} bs=1048576", once it completes do "/bin/sync" and powerdown, remove the old disk and hook up the new disk in it's place and reboot and usually everything works normally. [it does screw up drive geometry but since linux uses LBA adressing anyway this is irrelevant]
if there are read errors on the source drive you'll probably want to use dd_rescue instead of dd.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Okey, picking the one I think is the least likely to lead to a flamewar (except regarding top-posting :)).
On Sun, Jun 12, 2005 at 12:10:52AM +0100, Peter Farrow wrote:
use G4U to clone it to an ftp server or second drive
much easier
I have not checked G4U yet, so I really mean this as a question:
How is it easier ? dump | restore is as straightfoward as it gets. I have been using it for 15+ years, and never had a problem (except for raiserfs filesystems, of course).
Yes, if I were going to produce a lot of copies of the same disk, then I would look for something like Ghost (or G4U, will check it later tonight). But for this particular task ?
all right then...I'll bite. All I've ever personally known is Norton Ghost which is why I'm so quick to mention its use. I'm, however, extremely curious and eagar to learn new techniques such as the one you're talking about. Why not lay the process out so's we can get a look at how to work it? I've got a few drives around, especially one that I'd like to clone that has some bad sectors on it that I really need a file from - its a program I wrote a while back that I simply don't want to have to re-write.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 09:11:47PM -0400, Mark Weaver wrote:
I have not checked G4U yet, so I really mean this as a question:
How is it easier ? dump | restore is as straightfoward as it gets. I have been using it for 15+ years, and never had a problem (except for raiserfs filesystems, of course).
Yes, if I were going to produce a lot of copies of the same disk, then I would look for something like Ghost (or G4U, will check it later tonight). But for this particular task ?
all right then...I'll bite. All I've ever personally known is Norton Ghost which is why I'm so quick to mention its use. I'm, however, extremely curious and eagar to learn new techniques such as the one you're talking about. Why not lay the process out so's we can get a look at how to work it? I've got a few drives around, especially one that I'd like to clone that has some bad sectors on it that I really need a file from - its a program I wrote a while back that I simply don't want to have to re-write.
Check my other post regarding this. Dump won't clone wholedisks. It will clone filesystems (with all metadata intact).
Also, there are at least 3 different versions of Norton Ghost, including one I never saw advertised, and only saw once at a computer manufacturing plant. Maybe it is just my lack of knowledge, but I found it much more interesting (not to mention fast and painless).
In any case, unless you are producing multiple copies, there is no real reason to clone the wholedisk. Actually, I would recomend against it. Get the new disk, partition it, clone the partitions you want (cloning the swap partition would be such a waste of time), reinstall the boot manager (which you would have to do anyway, unless you had the same bland/model/partnumber on both disks), and you are good to go.
Actully works much faster too.
As a side note, if you are cloning HD->HD and both are IDE, put them of different interfaces (hda and hdc, never hda and hdb). It will go much faster. I'm sure 99% of the subscribers know this already, but it is still worth mentioning for the other 1%.
Now, for making multiple copies of the same disk, the only tool I recomend is, yes, Norton Ghost. But again, careful with boot managers. Most expecially lilo. This used to be a problem when I tried it, and might still be.
I keep pointing about the part number of the HD because more often then not people think that just because 2 HDs have the same brand and model, they will be identical. But I have seen some cases where that is not true, as using DD proved. The part number, on the other hand, was different for those.
As you said, one must use the correct tool for the correct task. Of course you are right. My point was just that ghost was not the best tool for that particular case.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sat, 11 Jun 2005, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 09:11:47PM -0400, Mark Weaver wrote:
I have not checked G4U yet, so I really mean this as a question:
How is it easier ? dump | restore is as straightfoward as it gets. I have been using it for 15+ years, and never had a problem (except for raiserfs filesystems, of course).
Yes, if I were going to produce a lot of copies of the same disk, then I would look for something like Ghost (or G4U, will check it later tonight). But for this particular task ?
all right then...I'll bite. All I've ever personally known is Norton Ghost which is why I'm so quick to mention its use. I'm, however, extremely curious and eagar to learn new techniques such as the one you're talking about. Why not lay the process out so's we can get a look at how to work it? I've got a few drives around, especially one that I'd like to clone that has some bad sectors on it that I really need a file from - its a program I wrote a while back that I simply don't want to have to re-write.
Check my other post regarding this. Dump won't clone wholedisks. It will clone filesystems (with all metadata intact).
The problem with a broken disk is that your filesystem may not be correct. And you can't do a fsck to correct the inconsistencies because the disk is not reliable.
That's why you require something like ddrescue, so you can copy everything that is still accessible and fill the blank spaces in with zero-blocks. So it doesn't abort or truncate the output like dd, maybe dd conv=noerror is similar but ddrescue has other features like proper status info during copying and decreasing blocksize when blocks fail to be read.
I have no experience with ghost, does it work if disks have read errors ? How does it handle them ?
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Dag Wieers wrote:
On Sat, 11 Jun 2005, Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 09:11:47PM -0400, Mark Weaver wrote:
I have not checked G4U yet, so I really mean this as a question:
How is it easier ? dump | restore is as straightfoward as it gets. I have been using it for 15+ years, and never had a problem (except for raiserfs filesystems, of course).
Yes, if I were going to produce a lot of copies of the same disk, then I would look for something like Ghost (or G4U, will check it later tonight). But for this particular task ?
all right then...I'll bite. All I've ever personally known is Norton Ghost which is why I'm so quick to mention its use. I'm, however, extremely curious and eagar to learn new techniques such as the one you're talking about. Why not lay the process out so's we can get a look at how to work it? I've got a few drives around, especially one that I'd like to clone that has some bad sectors on it that I really need a file from - its a program I wrote a while back that I simply don't want to have to re-write.
Check my other post regarding this. Dump won't clone wholedisks. It will clone filesystems (with all metadata intact).
The problem with a broken disk is that your filesystem may not be correct. And you can't do a fsck to correct the inconsistencies because the disk is not reliable.
That's why you require something like ddrescue, so you can copy everything that is still accessible and fill the blank spaces in with zero-blocks. So it doesn't abort or truncate the output like dd, maybe dd conv=noerror is similar but ddrescue has other features like proper status info during copying and decreasing blocksize when blocks fail to be read.
I have no experience with ghost, does it work if disks have read errors ? How does it handle them ?
so far I've noticed that if the errors aren't severe it does ok, however I've got one disk that is seriously messed up somewhere with some bad sectors and even with certain error flags set it still has a horrible time meaning it takes literally forever to clone the disk and get the data off it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 03:45:19AM +0200, Dag Wieers wrote:
Check my other post regarding this. Dump won't clone wholedisks. It will clone filesystems (with all metadata intact).
The problem with a broken disk is that your filesystem may not be correct. And you can't do a fsck to correct the inconsistencies because the disk is not reliable.
That's why you require something like ddrescue, so you can copy everything that is still accessible and fill the blank spaces in with zero-blocks. So it doesn't abort or truncate the output like dd, maybe dd conv=noerror is similar but ddrescue has other features like proper status info during copying and decreasing blocksize when blocks fail to be read.
I never tried ddrescue, so I can't comment.
But, as far as I remember, dump will only abort if you get an error on the writing side. Memory can be at fault here, tho.
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 12 Jun 2005, Rodrigo Barbosa wrote:
On Sun, Jun 12, 2005 at 03:45:19AM +0200, Dag Wieers wrote:
Check my other post regarding this. Dump won't clone wholedisks. It will clone filesystems (with all metadata intact).
The problem with a broken disk is that your filesystem may not be correct. And you can't do a fsck to correct the inconsistencies because the disk is not reliable.
That's why you require something like ddrescue, so you can copy everything that is still accessible and fill the blank spaces in with zero-blocks. So it doesn't abort or truncate the output like dd, maybe dd conv=noerror is similar but ddrescue has other features like proper status info during copying and decreasing blocksize when blocks fail to be read.
I never tried ddrescue, so I can't comment.
But, as far as I remember, dump will only abort if you get an error on the writing side. Memory can be at fault here, tho.
But dump expects that your filesystem can be trusted, that it is still consistent. Which, if you have a broken disk, is not (necessarily) the case.
I'm not talking about a backup mechanism, I'm sure dump has its use. But when you have a failing drive (which was the topic) you better not use something that expects a working filesystem and you most certainly want to recover your filesystem on the broken disk (fsck).
BTW An example of a broken filesystem could be that directories appear to be missing or filled with garbage. Recursively scanning through the filesystem could yield unexpected results.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Sat, 2005-06-11 at 22:26 -0300, Rodrigo Barbosa wrote:
Now, for making multiple copies of the same disk, the only tool I recomend is, yes, Norton Ghost. But again, careful with boot managers. Most expecially lilo. This used to be a problem when I tried it, and might still be.
I still disagree. There are several tools for cloning entire disks in Linux which use a combination of _native_ tools -- even NTFS (using the new resize tools, which don't require write access).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 07:37:46AM -0500, Bryan J. Smith wrote:
On Sat, 2005-06-11 at 22:26 -0300, Rodrigo Barbosa wrote:
Now, for making multiple copies of the same disk, the only tool I recomend is, yes, Norton Ghost. But again, careful with boot managers. Most expecially lilo. This used to be a problem when I tried it, and might still be.
I still disagree. There are several tools for cloning entire disks in Linux which use a combination of _native_ tools -- even NTFS (using the new resize tools, which don't require write access).
I know. My point is that ghost is much faster than those other options for wholedisk copies. At least, the ones I tried. And, again, comparing to that ghost edition I used on that computer manufacturing place.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2005-06-12 at 16:57 -0300, Rodrigo Barbosa wrote:
I know. My point is that ghost is much faster than those other options for wholedisk copies. At least, the ones I tried. And, again, comparing to that ghost edition I used on that computer manufacturing place.
Okay, I'll see you there on Ghost, Drive Copy/Image, etc...
They _will_ typically be faster because of the generic sector-by-sector copy. But I still trust the filesystem tools more.
On Sunday 12 June 2005 16:47, Bryan J. Smith wrote:
On Sun, 2005-06-12 at 16:57 -0300, Rodrigo Barbosa wrote:
I know. My point is that ghost is much faster than those other options for wholedisk copies. At least, the ones I tried. And, again, comparing to that ghost edition I used on that computer manufacturing place.
Okay, I'll see you there on Ghost, Drive Copy/Image, etc...
They _will_ typically be faster because of the generic sector-by-sector copy. But I still trust the filesystem tools more.
Ghost, at least Symantec Ghost 8.0, does not do a generic sector by sector copy on an ext2/3 filesystem, it copies file by file, even when cloning whole disks (so that it doesn't copy blank space).
On Mon, 2005-06-13 at 13:10 -0400, Lamar Owen wrote:
Ghost, at least Symantec Ghost 8.0, does not do a generic sector by sector copy on an ext2/3 filesystem, it copies file by file, even when cloning whole disks (so that it doesn't copy blank space).
Don't confuse "generic sector-by-sector" with "filesystem block-by- block." _Huge_ difference.
Pretty much these programs (Ghost, Drive Copy/Image) use the _same_ approach. They _always_ copy, _generically_, sector-by-sector -- very fast, very direct. They use "filesystem-specific modules" to identify the used space as well as modify filesystem meta-data for moving/resizing.
Traditional archive programs use intelligent filesystem block-by-block access. Dump programs do similar, but at a lower, filesystem-specific level. But both are typically going to be slower -- especially traditional archiving.
On Sat, 2005-06-11 at 21:39 -0300, Rodrigo Barbosa wrote:
How is it easier ? dump | restore is as straightfoward as it gets. I have been using it for 15+ years, and never had a problem (except for raiserfs filesystems, of course).
Rodrigo is correct. UNIX filesystem "dumps" do what Ghost, Drive Copy/Image, etc... do for NT filesystems. Microsoft does _not_ offer an equivalent, let alone the nasty SAM-SID non-sense, hence their existence.
Otherwise, I also use the archive/unarchive method either via 'find|cpio -p' or 'tar c|tar x'. That will work with ReiserFS too, let alone just about any UNIX flavor
Yes, if I were going to produce a lot of copies of the same disk, then I would look for something like Ghost (or G4U, will check it later tonight). But for this particular task ?
There are broadcast/multicast tools for UNIX as well.
Peter Farrow wrote:
use G4U to clone it to an ftp server or second drive
much easier
blast! the site is down... I'm really interested to see this critter.
On Sat, 11 Jun 2005, Maciej ?enczykowski wrote:
A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit!
well if you want a real quick'n'dirty way to do it then you can simply turn off the computer, hook up the drive, boot with kernel command line init=/bin/bash, watch the messages for info on what device name the new drive got and do "/bin/dd if=/dev/hd{source} of=/dev/hd{target} bs=1048576", once it completes do "/bin/sync" and powerdown, remove the old disk and hook up the new disk in it's place and reboot and usually everything works normally. [it does screw up drive geometry but since linux uses LBA adressing anyway this is irrelevant]
if there are read errors on the source drive you'll probably want to use dd_rescue instead of dd.
I'd recommend doing the same using ddrescue and would suggest always using ddrescue as it provides you with status information (progress, errors, ...) and doesn't bail out if you get input/output errors.
And if you ever have filesystem errors (if the system wants to use fsck), first check if you harddisk is not broken. As you don't want to run fsck on a broken disk and risk loosing all your data. In that case, first ddrescue everything to a new disk, and then perform an fsck.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 01:08:56PM -0400, Doug Eubanks wrote:
First, I am not a RedHat or linux newbie. I simply have not had to do what I am getting ready to do, and I want to see if I am going to run into a problems... My HDA drive is failing (I can hear the occasional click from it and I am seeing Smart errors, the transfer rate is slow but all my data is there). I have 3 partitions on it, the /, /boot/ and my game servers (this is also the drive the bootloader is on). Will this proceedure work ok to replace it with the minimum of downtime/reinstalling A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit! Any hangups or snags doing it this way? Thanks, Doug Eubanks doug@simflex.com
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 01:08:56PM -0400, Doug Eubanks wrote:
First, I am not a RedHat or linux newbie. I simply have not had to do what I am getting ready to do, and I want to see if I am going to run into a problems... My HDA drive is failing (I can hear the occasional click from it and I am seeing Smart errors, the transfer rate is slow but all my data is there). I have 3 partitions on it, the /, /boot/ and my game servers (this is also the drive the bootloader is on). Will this proceedure work ok to replace it with the minimum of downtime/reinstalling A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit! Any hangups or snags doing it this way? Thanks, Doug Eubanks doug@simflex.com
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
why not just use Norton Ghost and ghost an image of the current drive to a new drive, boot with the CentOS rescue CD, reinstall grub and you're done! definitely the easiest way I can think of.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 04:48:57PM -0400, Mark Weaver wrote:
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
why not just use Norton Ghost and ghost an image of the current drive to a new drive, boot with the CentOS rescue CD, reinstall grub and you're done! definitely the easiest way I can think of.
Possible reasons: 1) Not everyone has it 2) Not everyone has Windows 3) Not everyone is willing to pay for Ghost 4) Not everyone is willing to pay for Windows 5) Norton Ghost is not F/OSS 6) Everyone who has CentOS already has dump/restore, cpio, tar and cp
There real question becomes, then, why to use ghost (for this).
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 04:48:57PM -0400, Mark Weaver wrote:
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
why not just use Norton Ghost and ghost an image of the current drive to a new drive, boot with the CentOS rescue CD, reinstall grub and you're done! definitely the easiest way I can think of.
Possible reasons:
- Not everyone has it
- Not everyone has Windows
- Not everyone is willing to pay for Ghost
- Not everyone is willing to pay for Windows
- Norton Ghost is not F/OSS
- Everyone who has CentOS already has dump/restore, cpio, tar and cp
There real question becomes, then, why to use ghost (for this).
[]s
Rodrigo Barbosa rodrigob@suespammers.org
because it simply works with the least amount of possibility for error. Its a matter of using the right tool for the job. nothin more nothin less.
you can also get ghost to run form a bootable cd or floppy..:)
Mark Weaver wrote:
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 04:48:57PM -0400, Mark Weaver wrote:
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
why not just use Norton Ghost and ghost an image of the current drive to a new drive, boot with the CentOS rescue CD, reinstall grub and you're done! definitely the easiest way I can think of.
Possible reasons:
- Not everyone has it
- Not everyone has Windows
- Not everyone is willing to pay for Ghost
- Not everyone is willing to pay for Windows
- Norton Ghost is not F/OSS
- Everyone who has CentOS already has dump/restore, cpio, tar and cp
There real question becomes, then, why to use ghost (for this).
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org
because it simply works with the least amount of possibility for error. Its a matter of using the right tool for the job. nothin more nothin less.
Am Sa, den 11.06.2005 schrieb William Warren um 23:36:
you can also get ghost to run form a bootable cd or floppy..:)
That does not change anything to the fact that ghost is not free.
http://freshmeat.net/projects/g4l may be an alternate to Rodrigo's suggestion.
Alexander
P.S. Warren, you should learn to quote (to strip quotation), to not top-post and to shorten your overlong signature (19 lines!) [meant friendly]
If you use ghost, you need to edit fstab to make it look for ext 2 file systems as ghost doesn't copy the journal inode of ext 3.
then use tune2fs -j /dev/....... to add it back in and edit the fstab back to ext3 on the new drive...
William Warren wrote:
you can also get ghost to run form a bootable cd or floppy..:)
Mark Weaver wrote:
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 04:48:57PM -0400, Mark Weaver wrote:
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
why not just use Norton Ghost and ghost an image of the current drive to a new drive, boot with the CentOS rescue CD, reinstall grub and you're done! definitely the easiest way I can think of.
Possible reasons:
- Not everyone has it
- Not everyone has Windows
- Not everyone is willing to pay for Ghost
- Not everyone is willing to pay for Windows
- Norton Ghost is not F/OSS
- Everyone who has CentOS already has dump/restore, cpio, tar and cp
There real question becomes, then, why to use ghost (for this).
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org
because it simply works with the least amount of possibility for error. Its a matter of using the right tool for the job. nothin more nothin less.
Peter Farrow wrote:
If you use ghost, you need to edit fstab to make it look for ext 2 file systems as ghost doesn't copy the journal inode of ext 3.
then use tune2fs -j /dev/....... to add it back in and edit the fstab back to ext3 on the new drive...
well shucks! someone should've told me that before I ghosted my web server's hard drive, three hard drives of client machines and all the countless other "ext3" file systems that my boss has done in recent past using ghost. Darn, if we've known its not supposed to work then we may not have been able to do what we've already done. ;)
in short, yes it does and no you don't have to do anything special with fstab to make ghost work which is why I made the comment I did about it just working.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 09:06:26PM -0400, Mark Weaver wrote:
Peter Farrow wrote:
If you use ghost, you need to edit fstab to make it look for ext 2 file systems as ghost doesn't copy the journal inode of ext 3.
then use tune2fs -j /dev/....... to add it back in and edit the fstab back to ext3 on the new drive...
well shucks! someone should've told me that before I ghosted my web server's hard drive, three hard drives of client machines and all the countless other "ext3" file systems that my boss has done in recent past using ghost. Darn, if we've known its not supposed to work then we may not have been able to do what we've already done. ;)
in short, yes it does and no you don't have to do anything special with fstab to make ghost work which is why I made the comment I did about it just working.
Actually, both of you are right :)
Under normal condition, you can just ignore the journal metadata. However, if you are cloning right after a crash, you might want to be careful, since the filesystem might be inconsistent.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 09:06:26PM -0400, Mark Weaver wrote:
Peter Farrow wrote:
If you use ghost, you need to edit fstab to make it look for ext 2 file systems as ghost doesn't copy the journal inode of ext 3.
then use tune2fs -j /dev/....... to add it back in and edit the fstab back to ext3 on the new drive...
well shucks! someone should've told me that before I ghosted my web server's hard drive, three hard drives of client machines and all the countless other "ext3" file systems that my boss has done in recent past using ghost. Darn, if we've known its not supposed to work then we may not have been able to do what we've already done. ;)
in short, yes it does and no you don't have to do anything special with fstab to make ghost work which is why I made the comment I did about it just working.
Actually, both of you are right :)
Under normal condition, you can just ignore the journal metadata. However, if you are cloning right after a crash, you might want to be careful, since the filesystem might be inconsistent.
[]s
Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
you've got a point there because I have run into a few where there were definite filesystem problems that I couldn't get around. Which is why in another post I asked if you'd layout your process that you've mentioned. I'm really curious about how you're doing it. Anything Linux I can learn is always a good thing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 09:18:56PM -0400, Mark Weaver wrote:
you've got a point there because I have run into a few where there were definite filesystem problems that I couldn't get around. Which is why in another post I asked if you'd layout your process that you've mentioned. I'm really curious about how you're doing it. Anything Linux I can learn is always a good thing.
Here is the exact step-by-step procedure I follow:
1) Have both disks on the same machine. Lets say: - hda (IDE, original data) - sda (SCSI, target)
2) Boot the machine with a rescue CD or, if not possible, runlevel 1
3) Make sure you have a table (on paper) with the partition->filesystem relationship.
4) Use fdisk (cfdisk etc) to partition the new disk (sda)
5) Make sure you have all the /dev entries you need. If you don't, create them with mknod (usually not needed)
6.a) Mount the destination partition you want to copy data to somewhere. You will repeat this step for each partition.
6.a.1) # mkdir /dest # mke2fs /dev/sda1 # mount /dev/sda1 /dest
6.b) Alternatively, you can copy the partition directly over the old one. For that, you don't need to execute the 6.a step. You must make sure both partitions are the same size, to do this this way. Otherwise (or if you are not sure), use the procedure on 6.a.
Note: In both case, if you are doing this on a live system on runlevel 1, don't forget to remount the partition readonly during this procedure:
# mount -o remount,ro /
7) Copy the data.
7.a) In case you are following 6.a:
# dump -0f - / | (cd /dest; restore -xf -)
7.b) In case you are following 6.b:
# dump -0f - /dev/hda1 | restore -xf /dev/sda1
8) If needed, unmount the /dest partition
9) Repeat the procedure for all partition you want to
10) Turn off the machine, remove the old disk, and boot with the rescue disk again.
11) Mount the root partition on the disk somewhere:
# mkdir /r # mount /dev/sda1 /r
12) Chroot for the root partition
# chroot /r /bin/bash
13) Reconfigure your bootmanager as needed (lilo.conf, grub.conf, menu.lst), and reinstall it (lilo, grub-install etc)
14) Reboot the machine using the new system
This procedure is also recomended if you are moving a partition for a new HD. Of course, you don't need to worry with steps 10+ in that case. Depending on what you are copying, you can do that during normal operation (as long as you don't need that partition at that time). Just remember to remount it readonly.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forgot one more step :)
On Sat, Jun 11, 2005 at 10:38:23PM -0300, Rodrigo Barbosa wrote:
- Reconfigure your bootmanager as needed (lilo.conf, grub.conf, menu.lst), and reinstall it (lilo, grub-install etc)
13.1) If needed, adjust /etc/fstab too
- Reboot the machine using the new system
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Forgot one more step :)
On Sat, Jun 11, 2005 at 10:38:23PM -0300, Rodrigo Barbosa wrote:
- Reconfigure your bootmanager as needed (lilo.conf, grub.conf, menu.lst),
and reinstall it (lilo, grub-install etc)
13.1) If needed, adjust /etc/fstab too
- Reboot the machine using the new system
Rodrigo Barbosa rodrigob@suespammers.org
sweet! Thank you very much. This will certainly come in handy.
On Sat, 2005-06-11 at 17:36 -0400, William Warren wrote:
you can also get ghost to run form a bootable cd or floppy..:)
And I can use the distro's installer CD #1 to do the same. I can mount via NFS, SMB, etc...
I don't have to build a DOS boot disk, network client and countless other non-sense that may or may not be supported.
On Sat, 2005-06-11 at 17:17 -0400, Mark Weaver wrote:
because it simply works with the least amount of possibility for error. Its a matter of using the right tool for the job. nothin more nothin less.
Whoa! Sorry, but us long-time UNIX admins would greatly _differ_ with you.
I typically use 'find|cpio', and someone else mentioned 'dump|restore' and I know 'tar c|tar x' is yet another. These are _native_ tools of the UNIX platform.
Ghost, Drive Copy/Image, etc... are great for dealing with NT which doesn't like to be cloned. But in UNIX/Linux, the native tools of the OS are far better.
Bryan J. Smith wrote:
On Sat, 2005-06-11 at 17:17 -0400, Mark Weaver wrote:
because it simply works with the least amount of possibility for error. Its a matter of using the right tool for the job. nothin more nothin less.
Whoa! Sorry, but us long-time UNIX admins would greatly _differ_ with you.
I typically use 'find|cpio', and someone else mentioned 'dump|restore' and I know 'tar c|tar x' is yet another. These are _native_ tools of the UNIX platform.
Ghost, Drive Copy/Image, etc... are great for dealing with NT which doesn't like to be cloned. But in UNIX/Linux, the native tools of the OS are far better.
And you long time Unix admins are one of the biggest reasons I read this mailing list. While I do like ghost I have to confess to a small amount of baiting because it tends to extract this kind of conversation a little quicker. well let me say it tends to provoke a much wider range of knowledge with a single probe than just asking a question. Yeah...a little twisted, but its fun too.
Since a Unix/Linux guru/admin is what I want to be when I grow up, (my wife tells me thats not likely to happen - me growing up), I would love to hear about your process.
On Jun 12, 2005, at 8:45 AM, Mark Weaver wrote:
Since a Unix/Linux guru/admin is what I want to be when I grow up, (my wife tells me thats not likely to happen - me growing up), I would love to hear about your process.
one technique that works quickly and simply for *cloning* disks (i.e. you've got one disk that's already partitioned, has data on it, etc. and you've got another of the same make and model, and you want two exact copies) is to use dd. since it's a block-level operation, it couldn't care less about whatever sorts of filesystems you've put on the disk, it'll preserve the MBR and whatever bootloader you may have there, and so forth.
1. install source disk and target disk in a machine (hooray for hot- swap bays!) 2. boot from CD or from other disk (i.e. *not* the target disk) into single-user mode 3. dd if=/dev/sdb of=/dev/sdc bs=1024 (source disk is /dev/sdb, target is /dev/sdc)
-steve
--- If this were played upon a stage now, I could condemn it as an improbable fiction. - Fabian, Twelfth Night, III,v
Steve Huff wrote:
On Jun 12, 2005, at 8:45 AM, Mark Weaver wrote:
Since a Unix/Linux guru/admin is what I want to be when I grow up, (my wife tells me thats not likely to happen - me growing up), I would love to hear about your process.
one technique that works quickly and simply for *cloning* disks (i.e. you've got one disk that's already partitioned, has data on it, etc. and you've got another of the same make and model, and you want two exact copies) is to use dd. since it's a block-level operation, it couldn't care less about whatever sorts of filesystems you've put on the disk, it'll preserve the MBR and whatever bootloader you may have there, and so forth.
- install source disk and target disk in a machine (hooray for hot-
swap bays!) 2. boot from CD or from other disk (i.e. *not* the target disk) into single-user mode 3. dd if=/dev/sdb of=/dev/sdc bs=1024 (source disk is /dev/sdb, target is /dev/sdc)
-steve
yikes! that could be a potential problem for some of the "older" disks I've got lying around. apart from that it just seems too easy to be true, although that would be the mule in me looking for the hard way to do things. AWESOME! info...thanks.
On 6/12/05, Mark Weaver mdw1982@mdw1982.com wrote:
Steve Huff wrote:
- dd if=/dev/sdb of=/dev/sdc bs=1024 (source disk is /dev/sdb, target
is /dev/sdc)
Don't you get better performance with a larger bs=nnnn value? I don't have a clue what the optimum value should be.
Collins Richey wrote:
On 6/12/05, Mark Weaver mdw1982@mdw1982.com wrote:
Steve Huff wrote:
- dd if=/dev/sdb of=/dev/sdc bs=1024 (source disk is /dev/sdb, target
is /dev/sdc)
Don't you get better performance with a larger bs=nnnn value? I don't have a clue what the optimum value should be.
I just think it totally rocks that you can specify the block size instead of being locked into a 512 block size.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 09:16:39AM -0400, Steve Huff wrote:
one technique that works quickly and simply for *cloning* disks (i.e. you've got one disk that's already partitioned, has data on it, etc. and you've got another of the same make and model, and you want two exact copies) is to use dd. since it's a block-level operation, it couldn't care less about whatever sorts of filesystems you've put on the disk, it'll preserve the MBR and whatever bootloader you may have there, and so forth.
- install source disk and target disk in a machine (hooray for hot-
swap bays!) 2. boot from CD or from other disk (i.e. *not* the target disk) into single-user mode 3. dd if=/dev/sdb of=/dev/sdc bs=1024 (source disk is /dev/sdb, target is /dev/sdc)
I really don't recomend it. You will get all kinds of geometry related problems, not to mention it will take ages to copy.
From my experience, even with all the extra work you have to do copying each filesystem one by one, it is still faster (total time) and a wholedisk dd.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 12 Jun 2005, Rodrigo Barbosa wrote:
On Sun, Jun 12, 2005 at 09:16:39AM -0400, Steve Huff wrote:
one technique that works quickly and simply for *cloning* disks (i.e. you've got one disk that's already partitioned, has data on it, etc. and you've got another of the same make and model, and you want two exact copies) is to use dd. since it's a block-level operation, it couldn't care less about whatever sorts of filesystems you've put on the disk, it'll preserve the MBR and whatever bootloader you may have there, and so forth.
I really don't recomend it. You will get all kinds of geometry related problems, not to mention it will take ages to copy.
I don't see why one would have 'all kinds of geometry problems' doing this. Except for Windows maybe. Linux doesn't care, the bootloader might. But restoring the bootloader is trivial.
Also I don't see why it would take ages ? It seems to be pretty sequential, it doesn't have any filesystem overhead. And in case you have bad blocks it is able to reduce blocksize to recover as much as possible (which of course is slower during recovery, there's no alternative though), with a filesystem you're pretty much f*cked.
I'm not sure if you ever tried it, but dd (or ddrescue) is much faster than what you would normally see as throughput at the filesystem level, especialy when you have bad blocks.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 11:05:26PM +0200, Dag Wieers wrote:
Also I don't see why it would take ages ? It seems to be pretty sequential, it doesn't have any filesystem overhead. And in case you have bad blocks it is able to reduce blocksize to recover as much as possible (which of course is slower during recovery, there's no alternative though), with a filesystem you're pretty much f*cked.
When you are producing lots of copies, you don't want to copy empty space. DD will copy everything.
I'm not sure if you ever tried it, but dd (or ddrescue) is much faster than what you would normally see as throughput at the filesystem level, especialy when you have bad blocks.
True. That is why I said I recomend ghost for when you are producing multiple copies. Not for backup, and definitively not for a recovery procedure.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2005-06-12 at 21:56 -0300, Rodrigo Barbosa wrote:
True. That is why I said I recomend ghost for when you are producing multiple copies.
There are still ways to multicast/broadcast UNIX sessions. Even cat'ing an archive, piping through netcat to a broadcast address would do the same. But there are, formal utilities for this for UNIX/Linux as well. 100% open source.
Not for backup, and definitively not for a recovery procedure.
With UNIX/Linux, there's no difference. We don't need specialized tools to do such elementary things.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 08:54:54PM -0500, Bryan J. Smith wrote:
Not for backup, and definitively not for a recovery procedure.
With UNIX/Linux, there's no difference. We don't need specialized tools to do such elementary things.
When you need to deliver 30000 computers in a week yes, you need specialized tools, and every second reduced on the cloning procedure counts.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2005-06-12 at 23:15 -0300, Rodrigo Barbosa wrote:
When you need to deliver 30000 computers in a week yes, you need specialized tools, and every second reduced on the cloning procedure counts.
Well then, I would _not_ be using Ghost! I would be using hardware duplicators. ;->
My point was that for UNIX/Linux, Ghost doesn't offer anything but problems.
On Sun, 2005-06-12 at 08:45 -0400, Mark Weaver wrote:
And you long time Unix admins are one of the biggest reasons I read this mailing list.
Good. We aren't always right. We don't always know best. But we do typically know what works best of us on UNIX/Linux, which may or may not be the same for others.
While I do like ghost I have to confess to a small amount of baiting because it tends to extract this kind of conversation a little quicker. well let me say it tends to provoke a much wider range of knowledge with a single probe than just asking a question. Yeah...a little twisted, but its fun too.
I don't like it. Long story short, I've had some really bad experiences with a fellow technical author. Like him giving near-sermons on why we should use only [PK]Zip and Joliet ISO9660 extensions because they were "ubiquitous" versus UNIX-centric ones like USTar format and RockRidge ISO9660 extensions (let alone the fact you can use both extensions simultaneously ;-). He took a lot of his clients down paths that got them into trouble, and I (among others) had to bail them out.
Now my apologies for responding a little more than "strongly." But I've got some really bad taste left in my mouth from people like that. ;->
Since a Unix/Linux guru/admin is what I want to be when I grow up, (my wife tells me thats not likely to happen - me growing up), I would love to hear about your process.
Well, understand there are major limitations to NT. I've been deploying NT since the original NT 3.1 beta (I was an admin/tech at the largely end-user of the first native NT app in 1992-1995). Solutions like Ghost, Drive Copy/Image, etc... cater to such limitations. Ironically, OS/2 didn't have them, but Gates decided to forgo many OS/2 capabilities in NT (although he did introduce some others -- long story).
In UNIX, typically there are different ways to deal with copying files.
As someone mentioned, the absolute best solution is to use the "raw" filesystem "dump." It basically gives you what Ghost does -- only safer. Instead of a generic sector-by-sector copy of used sectors, it is a block-by-block copy of used blocks in the filesystem. Better than Ghost, some "dump" programs can run on _live_ filesystems (although sometimes it's only recommended from a snapshot).
Another, more filesystem-agnostic approach is to use the streaming archive utilities. While some people use tar (10KB block USTAR archive format) -- tar create (tar c) piped to tar extract (tar x), different tar versions have different options on different platforms and may or may not handle all special files correct. But what I've _always_ had work for me is [System-V] cpio (5KB block USTAR archive format) -- cpio in "pass-thru" mode.
In a nutshell, you pipe in a list of files, and cpio automatically copies them -- _raw_ -- to another location. We typically use find from the current directory, and pass the "don't cross filesystems" option (- mount on almost all UNIX flavors, -xdev on newer ones). "cpio -p" does the rest, although the "-md" options preserve all mode/modification info, and "d" creates directories as necessary. You can use "v" to verbosely list the paths processed, and "u" for an unconditional overwrite.
As someone else mentioned, _no_ form of "cp" should be trusted to do the same.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 01:56:08PM -0500, Bryan J. Smith wrote:
As someone mentioned, the absolute best solution is to use the "raw" filesystem "dump." It basically gives you what Ghost does -- only safer. Instead of a generic sector-by-sector copy of used sectors, it is a block-by-block copy of used blocks in the filesystem. Better than Ghost, some "dump" programs can run on _live_ filesystems (although sometimes it's only recommended from a snapshot).
One point that I might not have clarified enough on my "dump tutorial" is the difference from "dump DEVICE" and "dump FILESYSTEM", on the example:
# dump -0f - /dev/hda1
and
# dump -0f - /
I can't be 100% this is how all dump implementations work, but this is how it SHOULD work.
When you dump a device, you do exactly that. The whole filesystem is dumped, and you have a direct filesystem image. In other words, if your target is a partition _larger_ than the original, you will end up with some space lost there. This method is particularly good when you are dumping into a backup media, and will want to restore to the same original location.
Dumping a filesystem, on the other hand, will create a dump of each data class on the filesystem. So it will dump each file individually (including inode and metadata for that file). Actually, it will do that for anything with an inode entry (for inode based filesystems). So, you can have a larger partition/filesystem as a target, and the will end up with that extra space as free usable space. That is why, in this case, you have to use mkfs and mount the target filesystem before using restore.
I hope it is a bit more clear now.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Sun, 2005-06-12 at 13:56, Bryan J. Smith wrote:
In a nutshell, you pipe in a list of files, and cpio automatically copies them -- _raw_ -- to another location. We typically use find from the current directory, and pass the "don't cross filesystems" option (- mount on almost all UNIX flavors, -xdev on newer ones). "cpio -p" does the rest, although the "-md" options preserve all mode/modification info, and "d" creates directories as necessary. You can use "v" to verbosely list the paths processed, and "u" for an unconditional overwrite.
As someone else mentioned, _no_ form of "cp" should be trusted to do the same.
I've never had a problem on systems that have GNU cp (i.e. Linux) using 'cp --one-file-system -a ...' to copy complete filesystems as exactly as possible. 'rsync --one-file-system -aH ...' will work too. I'm not sure if anyone mentioned that that file-oriented copies: tar, cpio, cp, rsync, etc. allow the target to be on a different filesystem type than the source, while dump does not, and dd reproduces the original filesystem.
On Sun, 2005-06-12 at 20:52 -0500, Les Mikesell wrote:
I've never had a problem on systems that have GNU cp (i.e. Linux) using 'cp --one-file-system -a ...' to copy complete filesystems as exactly as possible.
Some implementations of "cp" still take issue with special files. E.g., the default behavior of cp and most other UNIX utilities is to access devices nodes, not copy them as the raw device file.
In GNU cp, "-a" = "-dpR" which doesn't handle anything other than links, files and directories proper, which can be an issue.
'rsync --one-file-system -aH ...' will work too.
Again, once you start getting into device nodes and other, special files than links, file and directories, you can have problems.
I'm not sure if anyone mentioned that that file-oriented copies: tar, cpio, cp, rsync, etc. allow the target to be on a different filesystem type than the source, while dump does not,
Correct. Which is why I like the USTAR archivers (cpio, tar, pax). You can't trust cp with inodes other than links, files and directories.
and dd reproduces the original filesystem.
And disk label/slice geometry. Not always ideal, even if Linux doesn't trust the device geometry, and overrides with the filesystems' geometry, by default.
On Sun, 2005-06-12 at 21:01, Bryan J. Smith wrote:
I've never had a problem on systems that have GNU cp (i.e. Linux) using 'cp --one-file-system -a ...' to copy complete filesystems as exactly as possible.
Some implementations of "cp" still take issue with special files. E.g., the default behavior of cp and most other UNIX utilities is to access devices nodes, not copy them as the raw device file.
In GNU cp, "-a" = "-dpR" which doesn't handle anything other than links, files and directories proper, which can be an issue.
'rsync --one-file-system -aH ...' will work too.
Again, once you start getting into device nodes and other, special files than links, file and directories, you can have problems.
Both handle special files/device nodes fine. There might be some cross platform issues, but since we are talking about replacing a drive that would not matter here.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 08:45:29AM -0400, Mark Weaver wrote:
(my wife tells me thats not likely to happen - me growing up)
I wonder if they used DD, Ghost or G4U to make our wives :)
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 08:45:29AM -0400, Mark Weaver wrote:
(my wife tells me thats not likely to happen - me growing up)
I wonder if they used DD, Ghost or G4U to make our wives :)
[]s
Ghost....it has to be a windows product ;)
Best Regards, Jon McCauley
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sun, Jun 12, 2005 at 08:45:29AM -0400, Mark Weaver wrote:
(my wife tells me thats not likely to happen - me growing up)
I wonder if they used DD, Ghost or G4U to make our wives :)
[]s
makes one wonder sometimes, doesn't it?
Hello Rodrigo,
Have you thought of trying g4u? It is free http://public.planetmirror.com/pub/g4u/ The main site is down for the moement (ISP problems from the looks of it).
jer
Saturday, June 11, 2005, 2:01:55 PM, you wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 04:48:57PM -0400, Mark Weaver wrote:
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
[]s
why not just use Norton Ghost and ghost an image of the current drive to a new drive, boot with the CentOS rescue CD, reinstall grub and you're done! definitely the easiest way I can think of.
Possible reasons:
- Not everyone has it
- Not everyone has Windows
- Not everyone is willing to pay for Ghost
- Not everyone is willing to pay for Windows
- Norton Ghost is not F/OSS
- Everyone who has CentOS already has dump/restore, cpio, tar and cp
There real question becomes, then, why to use ghost (for this).
[]s
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 03:58:31PM -0700, Jerry57 (GMail) wrote:
Hello Rodrigo,
Have you thought of trying g4u? It is free http://public.planetmirror.com/pub/g4u/ The main site is down for the moement (ISP problems from the looks of it).
After taking a look at both G4U and G4L, I noticed they are pretty much frontends to DD.
Closing a disk with DD is less than ideal, unless you have 2 identical disks (including same partnumber), as I have found out after some tries. You will get several geomery related problems, including a few that will take days or months to bite you.
Lets give a quick analysis of the other options:
- - cp : You might get filesystem related problems. It will work, but you might loose some data. Also, it has no way to copy filesystem metadata.
- - tar : Again, it works, but you might end up with the same problems you had with cp, loosing some inode data. Again, no way to copy filesystem metadata.
- - dump/restore: This tools are based on the filesystem architecture. There is no way to dump a whole disk, and you will need a different dump implementation for each filesystem type. But if you are dumping ext2/ext3 filesystem, or some other fs that has a dump implementation for it (jfs comes to mind), this will provide you with the most precise copy possible. If, on the other hand, you are using something like raiserfs, you are out of luck (raisefs-dump is nothing more than a wrapper around tar). Filesystem metadata is copied correctly.
Of course, if you want to do a wholedisk copy (including MBR a blank space), you will need DD, or that "forensic" mode for ghost.
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sat, Jun 11, 2005 at 03:58:31PM -0700, Jerry57 (GMail) wrote:
Hello Rodrigo,
Have you thought of trying g4u? It is free http://public.planetmirror.com/pub/g4u/ The main site is down for the moement (ISP problems from the looks of it).
After taking a look at both G4U and G4L, I noticed they are pretty much frontends to DD.
Closing a disk with DD is less than ideal, unless you have 2 identical disks (including same partnumber), as I have found out after some tries. You will get several geomery related problems, including a few that will take days or months to bite you.
Lets give a quick analysis of the other options:
- cp : You might get filesystem related problems. It will work, but
you might loose some data. Also, it has no way to copy filesystem metadata.
- tar : Again, it works, but you might end up with the same problems
you had with cp, loosing some inode data. Again, no way to copy filesystem metadata.
- dump/restore: This tools are based on the filesystem architecture.
There is no way to dump a whole disk, and you will need a different dump implementation for each filesystem type. But if you are dumping ext2/ext3 filesystem, or some other fs that has a dump implementation for it (jfs comes to mind), this will provide you with the most precise copy possible. If, on the other hand, you are using something like raiserfs, you are out of luck (raisefs-dump is nothing more than a wrapper around tar). Filesystem metadata is copied correctly.
Of course, if you want to do a wholedisk copy (including MBR a blank space), you will need DD, or that "forensic" mode for ghost.
[]s
Rodrigo Barbosa rodrigob@suespammers.org
precisely my point - the right tool for the job.
On 6/11/05, Rodrigo Barbosa rodrigob@suespammers.org wrote:
Possible reasons:
- Not everyone has it
- Not everyone has Windows
- Not everyone is willing to pay for Ghost
- Not everyone is willing to pay for Windows
- Norton Ghost is not F/OSS
- Everyone who has CentOS already has dump/restore, cpio, tar and cp
There real question becomes, then, why to use ghost (for this).
That's why God created ghost for linux, which is basically a wrapper for dd.
Am Sa, den 11.06.2005 schrieb Rodrigo Barbosa um 21:53:
On Sat, Jun 11, 2005 at 01:08:56PM -0400, Doug Eubanks wrote:
First, I am not a RedHat or linux newbie. I simply have not had to do what I am getting ready to do, and I want to see if I am going to run into a problems... My HDA drive is failing (I can hear the occasional click from it and I am seeing Smart errors, the transfer rate is slow but all my data is there). I have 3 partitions on it, the /, /boot/ and my game servers (this is also the drive the bootloader is on). Will this proceedure work ok to replace it with the minimum of downtime/reinstalling A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit! Any hangups or snags doing it this way? Thanks, Doug Eubanks doug@simflex.com
I would like to suggest using dump/restore to make the backup.
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
Rodrigo Barbosa rodrigob@suespammers.org
On the Fedora user list the question came up whether dump & restore are extended attributes aware. This is an issue i.e. when using SELinux. Do the tools take care?
Alexander
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tue, Jun 14, 2005 at 08:18:57PM +0200, Alexander Dalloz wrote:
Something like:
mount /dev/hdb1 /newroot dump -0f - / | (cd /newroot; restore -xf -)
On the Fedora user list the question came up whether dump & restore are extended attributes aware. This is an issue i.e. when using SELinux. Do the tools take care?
That depends very much on what you are calling extended attributes. I have no experience with SELinux, so I really can't make an educated guess on what you are talking about.
Care to enlight me ?
[]s
- -- Rodrigo Barbosa rodrigob@suespammers.org "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
On Tue, Jun 14, 2005 at 03:26:20PM -0300, Rodrigo Barbosa wrote:
That depends very much on what you are calling extended attributes.
ext3 extended attributes.
I have no experience with SELinux, so I really can't make an educated guess on what you are talking about. Care to enlight me ?
They're supported in dump version 0.4b40. The CentOS 4 dump rpm (0.4b37) doesn't include any patches, so I guess the answer is "not supported".
Am Di, den 14.06.2005 schrieb Matthew Miller um 20:31:
On Tue, Jun 14, 2005 at 03:26:20PM -0300, Rodrigo Barbosa wrote:
That depends very much on what you are calling extended attributes.
ext3 extended attributes.
I have no experience with SELinux, so I really can't make an educated guess on what you are talking about. Care to enlight me ?
They're supported in dump version 0.4b40. The CentOS 4 dump rpm (0.4b37) doesn't include any patches, so I guess the answer is "not supported".
Thank you both Matthew and Rodrigo. So one will have to pay attention and have the need to relabel the filesystem after a restore when using SELinux.
Alexander
On Tue, Jun 14, 2005 at 08:44:28PM +0200, Alexander Dalloz wrote:
They're supported in dump version 0.4b40. The CentOS 4 dump rpm (0.4b37) doesn't include any patches, so I guess the answer is "not supported".
Thank you both Matthew and Rodrigo. So one will have to pay attention and have the need to relabel the filesystem after a restore when using SELinux.
The 'star' command *does* support extended attributes, by the way.
Try copying before restarting Linux, via network or something. I once saw a drive failing at my face after a restart :(
Good luck Oliver
Doug Eubanks wrote:
First, I am not a RedHat or linux newbie. I simply have not had to do what I am getting ready to do, and I want to see if I am going to run into a problems... My HDA drive is failing (I can hear the occasional click from it and I am seeing Smart errors, the transfer rate is slow but all my data is there). I have 3 partitions on it, the /, /boot/ and my game servers (this is also the drive the bootloader is on). Will this proceedure work ok to replace it with the minimum of downtime/reinstalling A> Make bootable floppy B> Start in single user mode C> Create same partition structure on hew drive D> Move all files from old partitions to new partitions E> Switch drives F> Boot off floppy, mount, reinstall grub and boot manager on new drive G> Profit! Any hangups or snags doing it this way? Thanks, Doug Eubanks doug@simflex.com
-
Alexander Dalloz -
Bryan J. Smith -
Collins Richey -
Dag Wieers -
Doug Eubanks -
Jerry57 (GMail) -
Jon McCauley -
Lamar Owen -
Les Mikesell -
Maciej Żenczykowski -
Mark Weaver -
Matthew Miller -
Oliver Schulze L. -
Peter Farrow -
Rodrigo Barbosa -
Steve Huff -
William Warren