DRIVE IMAG­ING 101

Up­grade to a speedy SSD the fast and easy way

Maximum PC - - FRONT PAGE - By Neil Mohr

Back in the July 2018 is­sue, we looked at some easy ways to keep your pre­cious data safely backed up. Part of the ra­tio­nale of any backup strat­egy is not to bother with any data that can be eas­ily down­loaded again, which is why back­ups usu­ally ig­nore boot drives these days. User fold­ers store con­fig­u­ra­tion files, and the gen­eral OS files are re­stored when you re­in­stall, right?

As true as that is, there’s still a cou­ple of ar­gu­ments for run­ning clone op­er­a­tions; one of the most com­mon is to mi­grate your boot me­dia, trans­fer­ring it from an old slow HDD, or per­haps shift­ing from an out­dated SSD to a more mod­ern one. The other ar­gu­ment is backup—while it’s true you can re­in­stall Win­dows from scratch, we all know how long that can take, and don’t get us started on up­dates. So, if a clone can be cre­ated eas­ily and quickly, it can of­fer a sim­ple way to deal with fu­ture prob­lems.

We’re go­ing to look at two op­tions, one that Mi­crosoft of­fers and the other an open-source so­lu­tion. The first is the tried and trusted Win­dows Sys­tem Im­age. It’s con­ve­nient, be­cause it can run live as you use your sys­tem, and it ties in to the de­fault Win­dows Re­cov­ery sys­tem. We’re also go­ing to look at the off-putting but in­cred­i­bly flex­i­ble Clonezilla, cre­ated back when ev­ery­thing was called project>zilla.

Cloning or imag­ing? We re­ally should get our par­lance sorted be­fore we con­tinue. When most peo­ple think of imag­ing a drive, it’s the process of copy­ing an en­tire drive or par­ti­tion to an im­age file stored else­where. In terms of drive cloning, peo­ple tend to think of “live imag­ing” of one drive or par­ti­tion to an­other drive or par­ti­tion on the fly.

Es­sen­tially, both pro­cesses are the same, it’s just the des­ti­na­tion that’s dif­fer­ent. Once a drive im­age is writ­ten to an­other drive, you’ve ac­com­plished the same cloned state, just with an ex­tra write step. To keep things sim­ple, we’ll call it all drive or par­ti­tion imag­ing; if we’re do­ing it disk-to-disk or disk-to-file, it’s hardly go­ing out of our way to say so.

Typ­i­cally with back­ups, an in­cre­men­tal op­tion should be avail­able. This is a drive im­age that only stores the bytes that have changed, so it’s quicker. Sounds use­ful, huh? An­noy­ingly, nei­ther the Mi­crosoft op­tion nor the open-source tool sup­port this, though it’s not out of the ques­tion.

To be fair on Mi­crosoft, imag­ing isn’t a well-re­garded way of back­ing up data these days, es­pe­cially if you can’t use an in­cre­men­tal sys­tem. It’s time-con­sum­ing, and even con­sid­ered point­less. If you have a boot drive larger than 240GB, you might want to con­sider an­other ap­proach or repar­ti­tion­ing, so your user data is stored sep­a­rately from Win­dows.

Unix-based op­er­at­ing sys­tems nailed this as­pect of sep­a­rat­ing user files from the OS a long time ago, in­sist­ing that all meat-bag data is stored (orig­i­nally) in a ded­i­cated /home folder, and in re­cent years on a /home par­ti­tion. This en­ables the OS files to be nuked from or­bit, re­in­stalled, and the world keeps on turn­ing, be­cause user files and con­fig files are safely stored away from the det­o­na­tion site. Win­dows 2000 did in­tro­duce some­thing sim­i­lar, but there’s still an un­holy mish­mash of files all over the place. It’s an­noy­ing.

THE MI­CROSOFT WAY

We’re go­ing to kick off by look­ing at the built-in Win­dows Sys­tem Im­age tool. Mi­crosoft tried to push peo­ple away from sys­tem im­ages when it in­tro­duced Win­dows 8, in its not so sub­tle way of killing off Win­dows 7 Backup and Re­store, which was orig­i­nally in­tro­duced in Win­dows Vista. Af­ter much Gen-X moan­ing, Mi­crosoft re­stored the sys­tem to Win­dows 8.1, and it re­mains tucked away in Win­dows 10 un­der the Con­trol Panel sec­tion in “Sys­tem and Se­cu­rity > Backup and Re­store (Win­dows 7).”

In its fa­vor, it’s pretty straight­for­ward to use, uses shadow copy to run in the back­ground as you work, and the re­cov­ery (usu­ally) works as part of the stan­dard re­cov­ery mode op­tions. The “usu­ally” com­ment there is in­serted as we have run into is­sues restor­ing im­ages made un­der dif­fer­ent ver­sions of Win­dows— as in, it won’t do that. Tech­ni­cally (and ac­tu­ally), you should make a re­cov­ery disc as a catch-all—you’re prompted to do this when an im­age is com­pleted.

Lim­i­ta­tions with Win­dows Sys­tem Im­age in­clude: min­i­mal op­tions (it only im­ages the en­tire sys­tem drive, and you can’t re­store in­di­vid­ual files af­ter); it only backs up to the root of a se­lected backup drive, and it only al­lows one im­age on there; it in­sists on a net­work user­name and pass­word for net­work shares, even if they have pub­lic ac­cess rights (in this case, you need to pro­vide the re­mote sys­tem’s stan­dard user­name and pass­word); and, as men­tioned, it doesn’t sup­port in­cre­men­tal back­ups, so it al­ways takes a long time to run.

Cre­at­ing a disk im­age with Mi­crosoft Sys­tem Im­age is pretty easy, but you need a sep­a­rate in­ter­nal drive, a spare ex­ter­nal

drive, a big stack of DVDs, or a net­work share to which you know the user­name and pass­word. Got that sorted? Good!

In “Search,” type “Con­trol,” and se­lect “Con­trol Panel.” Un­der “Sys­tem and se­cu­rity,” click “Backup and Re­store (Win­dows 7),” and click “Cre­ate a sys­tem im­age” on the left. It scans for what it con­sid­ers vi­able backup tar­gets. An ex­ter­nal drive or net­work share would be best, though any in­ter­nal drive is fine; as men­tioned, though, for any net­work share, even if it’s set for guest ac­cess, you need to pro­vide a suit­able user­name and pass­word. If ev­ery­thing ap­pears to work, click “Next.” You’re pro­vided with an es­ti­mate of the space re­quire­ments and a “Start backup” but­ton. Hit that, and you can con­tinue life as nor­mal, while the drive is im­aged in the back­ground.

To re­cover your PC, you have two op­tions: re­boot us­ing a re­cov­ery DVD, or start Win­dows in Re­cov­ery mode. If Win­dows runs, open the “Start” menu, type “Re­cov­ery,” and choose “Re­cov­ery op­tions.” Se­lect “Restart now” un­der “Ad­vanced startup.” Choose “Trou­bleshoot > Ad­vanced op­tions > Sys­tem im­age re­cov­ery.” Win­dows then re­boots into Re­cov­ery mode. You need the drive with the sys­tem im­age on plugged in to your com­puter. Fol­low the prompts, and your sys­tem tis re­stored.

THE OPEN WAY

So, the Mi­crosoft tool is lim­ited and slow, but it has saved our ba­con a cou­ple of times over the years. We look at other pro­pri­etary op­tions in the box below, but we’d like to fo­cus on the long-stand­ing in­dus­try tool Clonezilla. In de­vel­op­ment since in 2007, it’s an en­ter­prise-class diskimag­ing and re­store tool, with sup­port for over 20 filesys­tems, over six op­er­at­ing sys­tem types, and sec­tor-to-sec­tor copy for those it doesn’t sup­port. It has full net­work sup­port, a client-server mode, and sup­ports full en­cryp­tion of its im­ages. It’s be­yond the scope of this ar­ti­cle, but it also sup­ports Mul­ti­cast for multi-clone/ re­store to net­worked sys­tems, with PXE and WoL sup­port.

That’s all nice, but it means Clonezilla is more com­plex to use. It’s not helped by the fact that it has its roots in the Linux gar­den, so text-based in­ter­faces and in­de­ci­pher­able drive names are the or­der of the day. The flip side is that it’s su­per­flex­i­ble, and free to use any­where and on any­thing. And once you’ve run through the menu sys­tems, you soon learn what’s im­por­tant and what can be ig­nored.

Clonezilla is a “live disc” OS, which means you grab the ISO im­age from

www.clonezilla.org, and write it to ei­ther

a CD, DVD, or USB stick. You then boot your sys­tem off that. Get the “Al­ter­na­tive Stable” im­age, aka Ubuntu-based build, from www.clonezilla.org/down­loads.php —it’s about 220MB. This ver­sion can avoid po­ten­tial UEFI boot is­sues on new sys­tems. If you want to write this to a USB stick, the lat­est tool to do that is Etcher.io. Gather all that to­gether, write it to the USB stick, and come back when you’re ready.

Now work out how to boot your PC from a USB de­vice—many sys­tems of­fer an early “Boot” menu, ac­cessed by tap­ping F9 (HP), F12 (Dell, Len­ovo), F8 (Amibios), or F11 (Award BIOS) while it runs the power-up POSTs; oth­er­wise you need to hit Del, and fid­dle with your boot de­vice pri­or­ity set­tings in the BIOS/UEFI.

If all has gone well, you’re pre­sented with the glo­ri­ous text-based screen shown below. A rule of thumb here is to use the de­faults—you can’t re­ally go too wrong. We’re go­ing to take you through cre­at­ing an im­age of your boot drive and restor­ing that. We’ll talk about live imag­ing driv­eto-drive, and in the box on the left, we cover net­worked imag­ing, be­cause Samba net­work­ing takes a cou­ple more steps to set up.

Go­ing through the menu, “800x600” is more than enough pix­els for any­one, then “English lan­guage,” “De­fault US key­board lay­out,” and “Start Clonezilla.” Then you land at the first menu of im­port. Use the up/down ar­row keys to move up and down; switch be­tween “<OK>,” “<CAN­CEL>,” and main menu op­tions with the Tab key; and if you need to se­lect mul­ti­ple items, do that with the space bar.

Choose “de­vice-im­age” or “de­vicede­vice” mode—we’re not cov­er­ing the other op­tions. We’re se­lect­ing “de­vi­ceim­age” first, so hit En­ter. Next, choose the lo­ca­tion of the im­age file; we’re us­ing “lo­cal_dev” (lo­cal stor­age de­vice), so tap En­ter. For net­work ac­cess, you’d se­lect “sam­ba_server,” while if you have ac­counts for Ama­zon S3 or OpenS­tack, they would be use­ful for re­mote back­ups.

At this point, it prompts you to plug in your USB de­vice. Wait five sec­onds, then press En­ter. It now lists all the suit­able de­vices it can de­tect; this should in­clude the source drive you want to im­age, and the tar­get drive where you want to store the im­age. The list uses mod­ern Linux par­lance, such as “/dev/sda VBOX_ HARDDISK VBOX_HARDDISK_<LONG HEX NUM­BER> 163GB.” The ini­tial “/dev/ sdX” is the hu­man-read­able sys­tem la­bel for the drive; the first name is the de­tected hard­ware de­vice name; and the long name con­tain­ing hexa­dec­i­mal is the unique OS la­bel, end­ing with the to­tal ca­pac­ity.

If those look cor­rect, press Ctrl-C, and Clonezilla scans for par­ti­tions. This re­sults in an­other overly com­plex-look­ing list. You should rec­og­nize the de­vice la­bels

“sda,” “sdb,” and so on that de­note drives, while the par­ti­tions on each drive are num­bered “sda1,” “sda2,” and so on for one drive, and “sdb1,” “sdb2,” etc. for the next drive. Each fol­low­ing la­bel con­sists of “<ca­pac­ity>_<file sys­tem>_<drive la­bel> _<de­vice name>_<OS Unique ID>.” Se­lect the tar­get drive to save the im­age to; if you’ve named it, look for the “<drive la­bel>” sec­tion. Se­lect it, then press En­ter.

You’re pre­sented with a “Di­rec­tory Browser.” If your backup drive is blank, it just has a con­fus­ing “<ABORT>” se­lec­tion, but if you have sub-di­rec­to­ries, these are listed and se­lectable. Don’t worry—each im­age cre­ates its own folder any­way. Tap Tab twice to se­lect “<DONE>,” then press En­ter to use the root to store im­ages.

Se­lect “Begin­ner” mode, then we need to se­lect the backup style. To keep things sim­ple, we’re go­ing to fo­cus on “savedisk,” as in the en­tire drive—for a typ­i­cal Win­dows boot drive, this is three par­ti­tions, which you want to save: boot par­ti­tion, OS par­ti­tion, and a re­cov­ery par­ti­tion. If you’re re­cov­er­ing your im­age, se­lect the “re­store­disk” or “re­storeparts” op­tion—no­tice the “1-2-mdisks” op­tion, which en­ables multi-disk restora­tion if you’re do­ing a mass clone. Press En­ter to get this show on the road. Keep the de­fault date-based name. Fi­nally, se­lect the drive (or par­ti­tions, if that’s the op­tion you’ve cho­sen) to im­age, then press En­ter.

There’s a fi­nal batch of op­tions to go through. Choose “-sf­sck” to skip disk check­ing (it doesn’t work well on NTFS filesys­tems any­way); choose to ver­ify the fi­nal im­age; en­crypt the im­age for se­cu­rity if you want, but you need a strong pass­word; and it of­fers to power down when done. Hit En­ter twice to get started. There’s a fi­nal “Press (y/n)” to get started, be­fore a de­tailed progress dis­play is shown. Even on older spin­ning drives, imag­ing a boot drive shouldn’t take much longer than 15 min­utes, un­less its ca­pac­ity is in the ter­abyte range. SSD sce­nar­ios are sig­nif­i­cantly faster.

Restora­tion of a drive is ex­actly the same—the ad­van­tage for Clonezilla is the im­ages are al­ways com­pat­i­ble, you can eas­ily get a fresh ISO to boot from, and im­ages can be stored any­where, even in the cloud—just af­ter the “Begin­ner” mode se­lec­tion, choose “Re­store­disk” mode.

Disk imag­ing isn’t a cure-all backup so­lu­tion, but it can help get a sys­tem back up faster than re­in­stalling, and is a real time-saver for de­ploy­ment sce­nar­ios.

The tar­gets in Win­dows Backup still in­clude DVDs.

It’s re­ally handy hav­ing a res­cue disc to hand in case of emer­gency.

If ev­ery­thing goes to plan, re­cov­ery is a smooth process.

Take your time, and you’ll find that the de­vice list does make sense.

Clonezilla’s file browser is su­per-ba­sic, but does the job.

Use the space bar if you need to multi-se­lect de­vices.

Clonezilla is pretty fast, and has a good time-re­main­ing es­ti­mate.

Newspapers in English

Newspapers from Australia

© PressReader. All rights reserved.