[opensuse] Copy One Hard Drive To Another Hard Drive(Backup)?
Copy One Hard Drive To Another Hard Drive(Backup)? Hi, I was running Win 8 until the release of 12.3. I am happy with 12.3 and will continue to use it. My question now is how would I copy a 1TB HDD to another 1TB HDD for purposes of backup of data? I was hoping there was a program somewhere for 12.3 that would do the above using a convenient GUI, but I can't find one. (I would prefer a program with a GUI - not Terminal commands or BootCD) Thanks! Jesse -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/23/2013 08:07 PM, Jesse Palser wrote:
Copy One Hard Drive To Another Hard Drive(Backup)?
Hi,
I was running Win 8 until the release of 12.3. I am happy with 12.3 and will continue to use it.
My question now is how would I copy a 1TB HDD to another 1TB HDD for purposes of backup of data?
I was hoping there was a program somewhere for 12.3 that would do the above using a convenient GUI, but I can't find one. (I would prefer a program with a GUI - not Terminal commands or BootCD)
probably best do from terminal : ~ maybe use "dd' : something like : dd if=/dev/[source-drive] of=/dev/[target-drive] .............. or . . . rsync is really good . . . something like : _______________________ mount -t ext4 /dev/[target-drive] /mnt cd rsync -avr --delete --delete-after --exclude=/dev/shm --exclude=/media --exclude=/mnt --exclude=/proc --exclude=/run --exclude=subdomain --exclude=/sys --exclude=/tmp --exclude=/var/lib/ntp --exclude=/var/run --exclude=/var/tmp / /mnt cd umount /mnt ______________ best regards .................... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, Apr 23, 2013 at 1:39 PM, ellanios82 <ellanios82@gmail.com> wrote:
probably best do from terminal :
~ maybe use "dd' :
something like :
dd if=/dev/[source-drive] of=/dev/[target-drive]
Add "bs=4K conv=noerror, sync" 4K can be as big as you want, but the default 512 bytes is smaller than the linux kernel pagesize and at least in some scenarios it makes the copy run dog slow. Also the default behavior of dd to a media error is to abort. You don't want that, so noerror says to continue even if you hit a media error. Sync is a modifier to noerror that says if a read error is encountered, pad the output with nulls to keep everything in sync. That is with just noerror an error in block 3 would get you: 1 2 4 5 For a filesystem with millions of blocks, have all the ones after the readerror offset by one makes it useless. With sync you get: 1 2 0 4 5 Obviously the block with an error is garbage but now the rest of the drive is properly aligned. fyi: If you want to save the output to a file instead of as a clone, then I suggest you use ewfacquire. It is specially designed to do that one job. It puts internal CRCs within the "image" and it can calculate various hashes to let you use ewfverify to check the overall consistency of the image. You use ewfexport to pull the data back out. ie. ewfexport image_file.E01 > /dev/sdb ewfacquire, ewfverify, and ewfexport all in the ewftools package which is part of OS 12.2 and 12.3 fyi2: guymager is a gui that can manage this process. I have it partially built in my OBS home project, but I've been happily ignoring it for about a year, so if someone with programming skills wants to branch it, fix it and SR it back to me, I'd be happy to at least push it into a devel project. I might even push it into factory. (I have the skills, I just haven't taken the time. Greg -- Greg Freemyer Chief Technology Officer Intelligent Avatar Corporation (678) 653-4860 Greg.Freemyer@gmail.com http://www.linkedin.com/in/gregfreemyer CNN/TruTV Aired Forensic Imaging Demo - http://insession.blogs.cnn.com/2010/03/23/how-computer-evidence-gets-retriev... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-23 at 16:07 -0400, Greg Freemyer wrote:
That is with just noerror an error in block 3 would get you:
1 2 4 5
For a filesystem with millions of blocks, have all the ones after the readerror offset by one makes it useless. With sync you get:
1 2 0 4 5
Obviously the block with an error is garbage but now the rest of the drive is properly aligned.
I like that explanation. In those cases, though, I prefer to use "dd_rescue", or rather, the script "dd_rhelp".
fyi: If you want to save the output to a file instead of as a clone, then I suggest you use ewfacquire. It is specially designed to do that one job. It puts internal CRCs within the "image" and it can calculate various hashes to let you use ewfverify to check the overall consistency of the image. You use ewfexport to pull the data back out.
Interesting. I'll have a look at that. For 12.1 and 11.4 it is in the security repo. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlF3J34ACgkQtTMYHG2NR9VvQQCdE0rYbPwI6NE5pFy3kj18D8DU +mMAnRCJocA3aEzavyW3qSiMpu28NriG =oz4H -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
"Carlos E. R." <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Tuesday, 2013-04-23 at 16:07 -0400, Greg Freemyer wrote:
That is with just noerror an error in block 3 would get you:
1 2 4 5
For a filesystem with millions of blocks, have all the ones after the readerror offset by one makes it useless. With sync you get:
1 2 0 4 5
Obviously the block with an error is garbage but now the rest of the drive is properly aligned.
I like that explanation.
In those cases, though, I prefer to use "dd_rescue", or rather, the script "dd_rhelp".
fyi: If you want to save the output to a file instead of as a clone, then I suggest you use ewfacquire. It is specially designed to do that one job. It puts internal CRCs within the "image" and it can calculate various hashes to let you use ewfverify to check the overall consistency of the image. You use ewfexport to pull the data back out.
Interesting.
I'll have a look at that. For 12.1 and 11.4 it is in the security repo.
If you have questions about any of the ewftools, feel free to ask me. I packaged them. The upstream dev (Joachim Metz) works for Google and has a number of security libraries/tools that I am in the middle of packaging for OS 13.1. The most intriguing is libvshadow that parses the volume shadow copies inside a ntfs filesystem image. They all work with images made via ewf acquire or with raw (pure dd) images. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
On Tue, Apr 23, 2013 at 1:39 PM, ellanios82 <ellanios82@gmail.com> wrote:
probably best do from terminal :
~ maybe use "dd' :
something like :
dd if=/dev/[source-drive] of=/dev/[target-drive]
Add "bs=4K conv=noerror, sync"
If it has 64M buffer, best to use the buffer size to achive optimal throughput.
4K can be as big as you want, but the default 512 bytes is smaller than the linux kernel pagesize and at least in some scenarios it makes the copy run dog slow. Also the default behavior of dd to a media error is to abort. You don't want that, so noerror says to continue even if you hit a media error. Sync is a modifier to noerror that says if a read error is encountered, pad the output with nulls to keep everything in sync.
--- Ug... I would rather have it die and try again -- sometimes a reread will work... if you have to copy a known bad disk, then what you suggest is reasonable, but on disks with no known problems...??? Also use.... dd besides the if=dev of=dev & bs=64M, you would want iflag=direct, oflag=direct. No GUI will beat it's speed... The direct flags will net you an extra 20-30% speed. If the disk buffers are 32M, use that as the copy size...(etc...)... I duped a windows disk using cygwin's 'dd' from an old SSD to a 1TB drive, then to the new SSD -- worked great! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
--- Ug... I would rather have it die and try again -- sometimes a reread will work... if you have to copy a known bad disk, then what you suggest is reasonable, but on disks with no known problems...??? On the subject of using 'dd' to read from a disk which has known bad sectors, Have a look at the 'ddrescue' utility which will retry reads: http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html The contents of this email are confidential and for the exclusive use of the intended recipient. If you receive this email in error you should not copy it, retransmit it, use it or disclose its contents but should return it to the sender immediately and delete your copy.
Hearns, John wrote:
--- Ug... I would rather have it die and try again -- sometimes a reread will work... if you have to copy a known bad disk, then what you suggest is reasonable, but on disks with no known problems...???
On the subject of using 'dd' to read from a disk which has known bad sectors, Have a look at the 'ddrescue' utility which will retry reads: http://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html
Good idea. If you have a bad disk, you should use a special tool for it. Somehow this topic seems to have migrated from how to do disk to disk copy w/o using command line (and so many of us try to tell him the command line is by far the best for something this simple), to dealing with bad sector in a source disk... which fortunately for me, is a rare situation. But seriously dd is your most reliable be. A gui won't have the decades of use behind it. dd if=/dev/sda of=/dev/sdb bs=64M iflag=direct oflag=direct & pid=$! ^ ^ output file (destination) ^^ says to not waste time w/extra mem copies -input file (source disk) the & on the end puts it in background, and the pid=$! stores the process number of it then "kill -USR1 $pid" every once in a while and it will print out how much it has done: 18335302+0 records in 18335302+0 records out 9387674624 bytes (9.4 GB) copied, 34.6279 seconds, 271 MB/s Note, for the bs, above, adjust it to the size of the cache memory on your destination disk and be sure write-caching is enabled. That way when you write to it, it goes into the write cache FAST, and dd, can start reading the next block size while the destination disk is flushing it's buffer to disk... I.e. you'll get much better performance in doing the copy. But it's not a GUI...so it doesn't really answer your question...but I'd strongly recommend against using an arbitrary GUI product for something this simple.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh <suse@tlinx.org> wrote:
Somehow this topic seems to have migrated from how to do disk to disk copy w/o using command line (and so many of us try to tell him the command line is by far the best for something this simple), to dealing with bad sector in a source disk... which fortunately for me, is a rare situation.
Linda, I do this procedure as part of my day job. (That's why I packaged ewfacquire, I use it routinely.) The "subject drives" which I read from are a random collection of customer drives. They can be a almost new drive in a new machine, all the way to a 10 year old drive in a computer sitting out in a shed that was almost forgotten about. Most are from desktop/laptop PCs a few years old and routinely in use. I don't keep stats, but I would guess between 5 and 10% of them have at least one bad sector. Having a significant number of bad sectors I agree is rare, but having one or two I would say is almost routine. In fact, I think the spec for new drives is no more than one bad sector in 10e10. 500gb drives have a billion sectors, so even with brand new drives having 1 in 10 have a bad sector would be in spec. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
Linda Walsh <suse@tlinx.org> wrote:
Somehow this topic seems to have migrated from how to do disk to disk copy w/o using command line (and so many of us try to tell him the command line is by far the best for something this simple), to dealing with bad sector in a source disk... which fortunately for me, is a rare situation.
Linda,
I do this procedure as part of my day job.
--- My condolences! ;-)
(That's why I packaged ewfacquire, I use it routinely.)
I am sure it is better for treating bad disks than 'dd'
The "subject drives" which I read from are a random collection of customer drives. They can be a almost new drive in a new machine, all the way to a 10 year old drive in a computer sitting out in a shed that was almost forgotten about. Most are from desktop/laptop PCs a few years old and routinely in use.
I don't keep stats, but I would guess between 5 and 10% of them have at least one bad sector. Having a significant number of bad sectors I agree is rare, but having one or two I would say is almost routine.
---- Um, are you saying a typical user should expect to see 1-2 disk errors on a disk->disk copy? Isn't it fair to say that many consumer level drives not only have 1-2 disk errors, but already have such sectors remapped to per-track spares when new? For that matter, if it isn't a drive nearing it's "end of useful life", would you expect users to actually see or notice such an error -- or wouldn't it be handled by the drives internal firmware -- w/recovery via internal ECC and remapping all handled on the fly? Isn't, by 'SMART' standards, a drive at the end of its useful lifespan when it can no longer automatically relocate such data automatically? Isn't it *normally* the case that a user will only see disk errors on a drive that can no longer remap sectors?
In fact, I think the spec for new drives is no more than one bad sector in 10e10. 500gb drives have a billion sectors, so even with brand new drives having 1 in 10 have a bad sector would be in spec.
---- But you are talking raw sectors -- not formatted capacity, no? Wouldn't the MTBF say, a new, 5-year warranty Hitachi 4TB drive rated at 1-2 million hours (for DeskStar V. Ultrastar models) sort of imply that most users will never see a disk error during the useful life of that disk?
Greg
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-04-24 at 15:15 -0700, Linda Walsh wrote:
Isn't it fair to say that many consumer level drives not only have 1-2 disk errors, but already have such sectors remapped to per-track spares when new? For that matter, if it isn't a drive nearing it's "end of useful life", would you expect users to actually see or notice such an error -- or wouldn't it be handled by the drives internal firmware -- w/recovery via internal ECC and remapping all handled on the fly? Isn't, by 'SMART' standards, a drive at the end of its useful lifespan when it can no longer automatically relocate such data automatically?
Isn't it *normally* the case that a user will only see disk errors on a drive that can no longer remap sectors?
No. The remapping is done only when you attempt to write to a bad sector, then it is remapped. If you attempt to read from a bad sector, it simply fails.
But you are talking raw sectors -- not formatted capacity, no? Wouldn't the MTBF say, a new, 5-year warranty Hitachi 4TB drive rated at 1-2 million hours (for DeskStar V. Ultrastar models) sort of imply that most users will never see a disk error during the useful life of that disk?
My laptop developed just one bad sector at about 4000 hours of use. I did immediately image that partition with dd_rescue. Withing days, while I waited for the replacement dis, I got about a dozen more of bad sectors each time I tested (affecting just one partition, AFAIK). And it is just 500 GB. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlF4XFQACgkQtTMYHG2NR9XYdQCgkaY0/DZ4+Kx49oyvnPPL7JiE tyEAn2cGNP97fnz1MMLLxXJtvlyO6v0I =otHA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Linda Walsh <suse@tlinx.org> wrote:
Greg Freemyer wrote:
Linda Walsh <suse@tlinx.org> wrote:
Somehow this topic seems to have migrated from how to do disk to
disk
copy w/o using command line (and so many of us try to tell him the command line is by far the best for something this simple), to dealing with bad sector in a source disk... which fortunately for me, is a rare situation.
Linda,
I do this procedure as part of my day job.
My condolences! ;-)
(That's why I packaged ewfacquire, I use it routinely.)
I am sure it is better for treating bad disks than 'dd'
The "subject drives" which I read from are a random collection of customer drives. They can be a almost new drive in a new machine, all the way to a 10 year old drive in a computer sitting out in a shed that was almost forgotten about. Most are from desktop/laptop PCs a few years old and routinely in use.
I don't keep stats, but I would guess between 5 and 10% of them have at least one bad sector. Having a significant number of bad sectors I agree is rare, but having one or two I would say is almost routine.
---- Um, are you saying a typical user should expect to see 1-2 disk errors on a disk->disk copy?
I'm saying 90% of the time they should see 0 bad sectors, but 1 or 2 the other 10% of the time is expected and normal.
Isn't it fair to say that many consumer level drives not only have 1-2 disk errors, but already have such sectors remapped to per-track spares when new? For that matter, if it isn't a drive nearing it's "end of useful life", would you expect users to actually see or notice such an error -- or wouldn't it be handled by the drives internal firmware -- w/recovery via internal ECC and remapping all handled on the fly? Isn't, by 'SMART' standards, a drive at the end of its useful lifespan when it can no longer automatically relocate such data automatically?
You don't seem to understand the bad sector life cycle. Here you go: - Sector magnetism becomes degraded. - Time passes (hours, days, years) - A sector read of that specific sector occurs. - A sector error is returned to the userspace app and smart marks the sector bad - all subsequent reads continue to attempt to read from the same bad sector. That is they typically fail as well. - time passes (seconds, days, years) - a write to the bad sector occurs - drive controller notes this sector is bad, time to remap it - sector remapped and new data written - reads now succeed
Isn't it *normally* the case that a user will only see disk errors on a drive that can no longer remap sectors?
No, see the life cycle and the 2 different places an error can exist for years. Most raid1/5/6 solutions run scrubbers once a month or so to detect and correct these failures without degrading the raid array. Ie. They force the reading of every sector of the array. When an error is found they use the raid correction logic to calculate what it should have been and write the valid data back out. It is the write that triggers the remap. Thus a freshly scrubbed raid array should have 0 bad sectors, but a failure may occur before the next scrub. That is why you want to run a scrub every month or so. Note that for the raid scenario you don't want the drive to automatically retry failed reads. Instead you want it to try exactly once and fail immediately if there is a problem. That lets the raid solution handle it. Most will immediately write out the calculated data and thus fix the bad sector as soon as it is detected. Therefore a raid edition sata drive is actually less reliable than a consumer edition drive. The only difference is the firmware. It is the raid solution that makes the overall system more robust. That means if you are buying drives for a raid, then definately buy a raid edition drive, but if it is for standalone use avoid raid edition drives, they don't have auto retry logic built-in. Back to consumer systems. If a sector holds changing data, then the error will be found and corrected quickly, but assume it is part of unallocated space near the end of the drive. With a modern 500 gb disks, many of the sectors at the end of the drive will NEVER be read or written in the life of the drive under normal conditions. Bad sectors there just sit there in a failed state forever.
In fact, I think the spec for new drives is no more than one bad sector in 10e10. 500gb drives have a billion sectors, so even with brand new drives having 1 in 10 have a bad sector would be in spec.
---- But you are talking raw sectors -- not formatted capacity, no? Wouldn't the MTBF say, a new, 5-year warranty Hitachi 4TB drive rated at 1-2 million hours (for DeskStar V. Ultrastar models) sort of imply that most users will never see a disk error during the useful life of that disk?
No. Most new drives today do have zero bad sectors, but run smart on a several year old drive and you will rarely find one with zero remapped sectors. For it to be remapped it had to report bad at some point. That means a media error was reported at least once for every remapped sector reported by smart. (Remember the drives / kernel have retry logic so the error may not propagate to user space so even a tool like dd won't see all the bad sectors.) Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer said the following on 04/25/2013 08:52 AM:
You don't seem to understand the bad sector life cycle. Here you go:
- Sector magnetism becomes degraded. - Time passes (hours, days, years) - A sector read of that specific sector occurs. - A sector error is returned to the userspace app and smart marks the sector bad - all subsequent reads continue to attempt to read from the same bad sector. That is they typically fail as well. - time passes (seconds, days, years) - a write to the bad sector occurs - drive controller notes this sector is bad, time to remap it - sector remapped and new data written - reads now succeed
Damn Right! More years ago than I care to remember I wrote a package that did that for the old CDC 9766 300 MB style drives. Time passed (years) and now its all in the drive electronics :-) The only difference I can think of was that also wrote a utility to manipulate the 'look-aside' mapping so that I could map out a bad sector on the basis of it being logged as bad on reading. It was really up to the admin to try and do a best-effort of reconstituting the data. Still, back in those primitive days, the V7 UNIX file system had a mechanism whereby a hidden file (inode #0 was it?) could have bad blocks linked to it so that they were never allocated to a file. I don't think there was a tool to do this and I can't recall if the MKFS of those days did it for you - I think it didn't. We've come a long way since then. Those 300MB drives took two people to lift and load into a 19" rack. Now I have a 32GB "drive" that's the size of my thumb nail. -- Wherever you see a successful business, someone once made a courageous decision. --Peter F. Drucker -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 23/04/2013 19:39, ellanios82 a écrit :
On 04/23/2013 08:07 PM, Jesse Palser wrote:
Copy One Hard Drive To Another Hard Drive(Backup)?
Hi,
I was running Win 8 until the release of 12.3. I am happy with 12.3 and will continue to use it.
My question now is how would I copy a 1TB HDD to another 1TB HDD for purposes of backup of data?
I was hoping there was a program somewhere for 12.3 that would do the above using a convenient GUI, but I can't find one. (I would prefer a program with a GUI - not Terminal commands or BootCD)
probably best do from terminal :
~ maybe use "dd' :
something like :
dd if=/dev/[source-drive] of=/dev/[target-drive]
..............
or . . . rsync is really good . . . something like :
* dd is not safe. * For such a size, avoid graphical tools. * So prepare your partition, and use rsync instead : rsync -r -P -t --progress source destination Dsant, from France -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/24/2013 12:21 PM, Dsant wrote:
* dd is not safe. * For such a size, avoid graphical tools. * So prepare your partition, and use rsync instead : rsync -r -P -t --progress source destination
Could you explain why "dd is not safe"? mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Le 24/04/2013 19:35, Mark Hounschell a écrit :
On 04/24/2013 12:21 PM, Dsant wrote:
* dd is not safe. * For such a size, avoid graphical tools. * So prepare your partition, and use rsync instead : rsync -r -P -t --progress source destination
Could you explain why "dd is not safe"?
mark
Tell me if I am wrong, but dd does not know about partition format consistency , files and folders, or checksums. So if you have the choice between dd and rsync, rsync will complain if CRC is wrong. The best would be that the tool would re-read what have been written, as for CD-RW. Dsant, from France -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/24/2013 01:50 PM, Dsant wrote:
Le 24/04/2013 19:35, Mark Hounschell a écrit :
On 04/24/2013 12:21 PM, Dsant wrote:
* dd is not safe. * For such a size, avoid graphical tools. * So prepare your partition, and use rsync instead : rsync -r -P -t --progress source destination
Could you explain why "dd is not safe"?
mark
Tell me if I am wrong, but dd does not know about partition format consistency , files and folders, or checksums. So if you have the choice between dd and rsync, rsync will complain if CRC is wrong. The best would be that the tool would re-read what have been written, as for CD-RW.
It does not know or care about "about partition format consistency , files and folders, or checksums". It does a sector by sector copy. The only problems I know about are when the 2 disks are not of the same size, and or, when the original disk is a "system" disk and the OS is configured for other than by device name. Even then it's easy to make it right. Mark -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2013-04-23 at 13:07 -0400, Jesse Palser wrote:
Copy One Hard Drive To Another Hard Drive(Backup)?
Hi,
I was running Win 8 until the release of 12.3. I am happy with 12.3 and will continue to use it.
My question now is how would I copy a 1TB HDD to another 1TB HDD for purposes of backup of data?
Data only, not system? I would use rsnapshot or rdiff-backup. CLI.
I was hoping there was a program somewhere for 12.3 that would do the above using a convenient GUI, but I can't find one. (I would prefer a program with a GUI - not Terminal commands or BootCD)
A list: amanda dar rdiff-backup rsnapshot gadmin-rsync? http://www.dirvish.org/ pdumpfs (http://0xcc.net/pdumpfs) duplicity duply Back-In-Time (http://backintime.le-web.org/) LuckyBackup deja-dup dropbox duplicity However, considering the disks are of the same size, I would use dd as ellanios82 told you. The second disk is an exact clone so that you can replace one with the other. The target has to be the exact same size or bigger, never smaller. Or, you can use "partimage", which is a text mode GUI. *Warning*: neither of those tools can be run from the same hard disk as you are going to clone, you have to boot a CD or USB stick live and run from it. There are Linux distributions dedicated to this, I use sysresccd (http://www.sysresccd.org/). You can also try the openSUSE 12.3 rescue image. This is absolutely necesary. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlF2yvQACgkQtTMYHG2NR9WG1QCdGjS8Kk6T4iEteIOxUrl2sUA1 uXkAniEGq+aZIiCFcsKxpItGfJVYxJRF =8hG1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
A list:
amanda dar rdiff-backup rsnapshot gadmin-rsync? http://www.dirvish.org/ pdumpfs (http://0xcc.net/pdumpfs) duplicity duply Back-In-Time (http://backintime.le-web.org/) LuckyBackup deja-dup dropbox duplicity
Don't forget unison -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-04-24 at 10:03 +0100, Dave Howorth wrote:
Carlos E. R. wrote:
Don't forget unison
No, unison is not a backup tool. It copies in any direction so that you have the newest copy on both sides. It is wonderful if, for example, you work on the same set of files sometimes on the desktop, sometimes in the laptop; it copies from one to the other (or the other to the one) so that both sides have the same copy (the newest one). It is not appropriate to keep a backup copy of one machine on another or on another disk. It can do it, but it is not the best. - -- Cheers, Carlos E. R. (from 12.1 x86_64 "Asparagus" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iEYEARECAAYFAlF30bkACgkQtTMYHG2NR9XY8gCfTN0KAnXoWfMh9sgyAGX0JcCK y/MAnRLV99UWSlxvbN7X7zFDzm13R4e0 =R9Ov -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On Wednesday, 2013-04-24 at 10:03 +0100, Dave Howorth wrote:
Don't forget unison
No, unison is not a backup tool. It copies in any direction so that you have the newest copy on both sides. It is wonderful if, for example, you work on the same set of files sometimes on the desktop, sometimes in the laptop; it copies from one to the other (or the other to the one) so that both sides have the same copy (the newest one).
It is not appropriate to keep a backup copy of one machine on another or on another disk. It can do it, but it is not the best.
unison is a lot more flexible than you suggest. But even using it in the simple fashion you suggest will suffice to make a backup copy. Since by definition the newest files are on the active machine, they will be copied to the backup. It has a lot more options than that. You might also want to look at the section in the manual entitled "Keeping Backups", which describes keeping multi-generational backups. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/23/2013 08:07 PM, Jesse Palser wrote:
Copy One Hard Drive To Another Hard Drive(Backup)?
Hi,
I was running Win 8 until the release of 12.3. I am happy with 12.3 and will continue to use it.
My question now is how would I copy a 1TB HDD to another 1TB HDD for purposes of backup of data?
I was hoping there was a program somewhere for 12.3 that would do the above using a convenient GUI, but I can't find one. (I would prefer a program with a GUI - not Terminal commands or BootCD)
~ maybe worth getting used to using konsole as root, - very worthwhile to use "rsync" throughout the working day, to make frequent backups of ones work. ................ best wishes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (11)
-
Anton Aylward -
Carlos E. R. -
Dave Howorth -
Dsant -
ellanios82 -
Greg Freemyer -
Hearns, John -
James Knott -
Jesse Palser -
Linda Walsh -
Mark Hounschell