My G4L program can clone to local disk or usb flash. Use a 128G USB flash for my home machine, and to do my mom's machine as a backup. If hard disk were to crash, could quickly pop out the disk, and put in a new one, then boot from the usb flash or cd, and reimage. At the College, I had an ftp server in my classroom that was running 1G network, and would make a compressed image on the server. Could even to a PXE boot from machines to load the g4l and do an image. Even had g4l as a boot option in the grub menu, just had to modify the 40_custom file, and put the kernel file and ramdisk.lzma in the /boot directory. Have a script on the g4l image that can clean partitions, and it supports linux, ntfs, fat32 and even swap partitions. With fat32, it has to make multiple 2G files until disk is full due to the file size limit. Other ones don't have that issue, but fat32 is getting less and less common. Use lzop as compression program, since it is about twice as fast as gzip, and image is only about 10% larger. Program is on sourceforge, and is free, and has full source code if one wants to look at it. On 5 Apr 2018 at 0:59, Todd Chester wrote: Subject: Re: OT:Question on NVME disk direct access? To: users@xxxxxxxxxxxxxxxxxxxxxxx From: Todd Chester <ToddAndMargo@xxxxxxxx> Date sent: Thu, 5 Apr 2018 00:59:39 -0700 Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> > > > On 04/04/2018 09:43 PM, Michael D. Setzer II wrote: > > > Thanks for the reply. There are lots of issues with doing cloning. > > Usually, doing a disk clone gets arround issues where the boot loader is > > using the blkid, since it makes the blikids for the partitions the same. Problem > > with that thou is that you can't have to disks in the same machine with the > > same blkids. Once cloned a disk, and then rebooted it to the OS without > > disconnecting, and for some reason, it mounted some partitions from the first > > disk, and others from the second? > > > > Same issue with the boot loaders using the /dev/sdx option. If you clone a > > disk on /dev/sda to /dev/sdb it works fine, but if you remove sda to test if it > > will boot, it will not since second disk with have sdb instead of the sda. Have > > to switch cables, or change boot order in bios. > > > > Contacted the person in charge of the nvme program, and he says it should > > work as it does with the virtualbox test I did. > > Chuckle. I have the same problem. My two backup drives and my clone > drive fit into a removable SATA drive sleeve. If I forget to remove > the clone drive after I do the clone, Fedora will boot off the clone > drive and mix things up as you describe. I researched as to why > this happens and it is all do to both drives having the same UUID > numbers on their partitions. > > I am not in my office at the moment, but when I do get back, I can > send you a bash script I wrote to warm me when this happens. Let > me know if you would like it. > > I frequently forget to swap out the clone drive and reinsert one > of the backup drives. The first clue is that it takes about > eight times longer to boot. > > > > User was using a windows program called eraser to clear the drive, but from > > what I have just found it seems to be a security eraser, and rights random > > data to the unused space as contrasted to writing nulls. Think the program > > was probable working just fine, but with completely random data the lzop > > compression doesn't work well. About twice the speed of gzip but 10% larger > > images. I could take a 1T disk, and compress it down to a 40G file with > > Windows 10 and Fedora 25 on it. > > If you what to completely blank a disk out, don't mess around with that > operating system whose name I shall not mention. (I hear it is slow, > buggy, and expensive.) Stay in Linux. > > # dd bs=1M if=/dev/zero of=/dev/sdx > > /dev/zero is the fastest, but you also have /dev/one which is slower > and /dev/random which is really slow. > > > > My classroom setup also, had and NFTS clone image file on a separate > > partitions, and had an grub boot option, that would reimage the 160G > > Windows 10 partition in about 12 minutes. About a 20G image file. > > > > Have a program on the g4l disk that will zero out the unused space, so have > > asked the user to try using that to clean disk, and then make image. > > > > Hopefully, that will result in the expected compression. > > Take a look at Clone Zilla, it does all that for you: > http://clonezilla.org/ > > The author is extremely responsive to questions too. > > I use Clone Zilla with its rescue mode (advanced setting) on > NTFS drives with bad sectors on them ALL THE TIME. > > What ?? Yes, I have to work on THAT operating system whose name I > shall not mentions too. My customer base is mainly small > businesses and they can not get apps to run on anything other > than THAT operating system. It is what it is. > > Tip: stay the hell away from Intel SSD drives. I use to sell them. > They are garbage. I took around a $2000 loss so far having to replace > them as they go bad in my customer's machines. > > I switched to Samsung SSD's and they are rock solid. Not a > single failure yet. They are about 20% more expensive than > Intel's drives, but when your have to replace them for free > and just before they brick and lose your customer's data, > they become extremely expensive. > > Samsung's NVMe drives are awesome. (My wife named them NeVada > Medical Examiner drives to remember the abbreviation.) > > Tip: try to size your SSD drives such that they have at least 50% > or more free space on them. This improves your wear life. And > the wear leveling algorithm on the drive will adore you. > > > > > > Thanks again for the info. > > You are most welcome. > > -T > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx +------------------------------------------------------------+ 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 65132161.613216 | ABC 16613838.513356 SETI 109336776.035164 | EINSTEIN 141004554.999240 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
