On 10 Sep 2018 at 19:05, wwp wrote:
Date sent: Mon, 10 Sep 2018 19:05:13 +0200
From: wwp <subscript(a)free.fr>
To: users(a)lists.fedoraproject.org
Subject: Re: OT: fastest way to copy one drive to another
Send reply to: Community support for Fedora users <users(a)lists.fedoraproject.org>
Hello Michael,
On Fri, 07 Sep 2018 13:00:17 +1000 "Michael D. Setzer II"
<msetzerii(a)gmail.com> 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@guam.net
mailto:msetzerii@gmail.com
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