On 10 Sep 2018 at 19:05, wwp wrote: Date sent: Mon, 10 Sep 2018 19:05:13 +0200 From: wwp <subscript@xxxxxxx> To: users@xxxxxxxxxxxxxxxxxxxxxxx Subject: Re: OT: fastest way to copy one drive to another Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> > Hello Michael, > > > On Fri, 07 Sep 2018 13:00:17 +1000 "Michael D. Setzer II" <msetzerii@xxxxxxxxx> wrote: > > > A number of good replies already, but just to add a note: > > I've been the maintainer of the g4l disk imaging project since 2004, and it > > basically uses dd for most operations. > > I'm replying, not only OT to the ML but OT to this thread, because I've > just experimented g4l for backing up several windows systems (for Linux > boxes I run my own rsync-based scripts) and wanted to share that. The > process was pretty simple: shutting them down, booting from the USB storage > where g4l resides (either legacy or UEFI mode), configured the process > to send to a FTP server over the LAN. The process is reliable and > pretty fast, approx 2h for each 500GB disk (RAW copy mode), I though > it would be longer. The only thing I added is generating a .md5 file on > storage, in case, that should be done by g4l IMO. For testing the image, since it is a compressed file and lzop and gzip both have a option to check the archive (-t) and it is a 32bit check, so don't know what adding a .md5 file to confirm the file versus checking the image. Did once have a brand new server that I was creating images on, and they were corrupt. Ran an memtest on system, and it turned out one of brand new 512M modules had an error that passed the first 7 tests with no error, but failed on the 8 test pattern. So in the docs recommend always using the compression program test to validate the image. > > My former experience were using a similar approach but with clonezilla > (in that time, no FTP sending but local storage or at least I couldn't > find it, and a slower process, less simple at least, partition by > partition and a user interface that is prone to user error), which led > me to back my Windows systems up way less often. > Generally recommend a full disk image the first time, the ntfsclone option only backs up used data on ntfs partitions, so is usually faster. G4L can be booted from a windows disk using grub4dos, was easy to add with 95 and 98 and XP as a boot option, 7 and above require making the grub4dos the primary boot manager, and you have to do some tricks in renaming files. Thanks for the info. There is a doc file on sourceforge, but not many download it. Working on version 0.55, and just did alpha 48. Just had a typhoon pass, and power was out for 23 hours, so just getting back online. Had 192 emails. > IOW, Michael, thanks for providing g4l! > > > Regards, > > -- > wwp > +------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@xxxxxxxx mailto:msetzerii@xxxxxxxxx Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC@HOME CREDITS ROSETTA 65783064.026787 | ABC 16613838.513356 SETI 109522169.740739 | EINSTEIN 141379519.999240 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
