edadat

Hi there! My disks are Hitachi and Samsung, but thanks for the tip. Presumably - if you're performing a disk to disk clone - both the source and destination drives have to be Seagate for it to work? (not just one of the drives). Also, I wouldn't want my backup images to be tied to a particular drive manufacturer (if that is indeed the case). Yes, Ghost 2003 has been a good friend to me over the years too, but I came a cropper a couple of years ago when I tried to boot from the CD on a newer Intel chipset and it didn't like it. One of the reasons for looking for a more generic solution. Interesting, doesn't the built-in System Imaging meet your needs?

Just to update this thread with notes from the field. Over the last few days, I have conducted a number of mock backup/recovery procedures in order to establish which one I have most confidence in adopting. All my tests were conducted inside the BartPE environment. First up, ImageX. In short, the backup WIM files were successfully generated and the default fast compression gave a decent file size of ~45GB on a ~70GB NTFS partition. However, it took a very long time - around 9 hours - to generate the WIM file. As I planned to store the WIM file on a FAT32 external USB disk (FAT32 for cross-platform compatibility), I needed to convert the WIM files into split WIM files - SWMs - because of the 4GB FAT32 file size limit. Because this cannot be done as part of the image creation (it has to be done afterwards as a separate process), this increased the amount of time it took to create the backup by about an hour. The next step was to perform a mock restore of the SWMs to an internal drive. Having partitioned and formatted the drive, extracting took around about an hour. No need to add an NT bootsector with bootsect.exe - it booted straight into XP after a restart. Next up DriveImage XML BartPE plugin by RunTime software. This worked flawlessly. Backing up gives an option to split the files as it goes, though fast compression resulted in ~60GB of backup files, significantly more space than ImageX's file. Having said that, DIX took a lot less time to backup - around 3.5 hours. Restoring to another drive was simple. First, using diskpart, I created a new primary partition, made it active, launched DIX and restored. The only bit that I was unsure about was when a message popped up at the end of the restore: Your original boot record reports 16 heads while your new target drive reports 255 heads. Do you want to force the new target volume to the cloned volume? Yes No Yes was the preselected default so I rather blindly chose that option. Then I restarted and it booted straight into Windows XP without a hitch! My final test was to see whether I could simply create a spanned zip or 7zip archive of my entire system, and successfully restore it to another disk. Well all I can say is it works for me! The gist of what I did was: To backup Add 7z.exe and 7z.dll to BartPE %system32% folder Boot into BartPE If using an external drive to back up to, you need to assign a drive letter to it in Disk Management. From the command prompt, create the archive: 7z a -r -y -xr@exclude.txt "dest:\Windows_XP_backup.7z" source:\* -v3g -mx=1 -mtc=on (dest: is e.g. your external drive's drive letter and source: is the drive letter of the drive you want to backup) To restore Attach the disk to restore to, and boot into BartPE From a command prompt, launch diskpart: DISKPART SELECT DISK 0 DETAIL DISK CLEAN CREATE PARTITION PRIMARY LIST PARTITION SELECT PARTITION 1 ACTIVE ASSIGN LETTER=C EXIT Format the partition FORMAT C: /FS:NTFS /V:PATA-1 /Q Restore the archive with: 7z x -y "source:\Windows_Xp_backup.7z.001" -oC: (source: is e.g. your external drive's drive letter and C: is the drive letter of the drive you want to restore to) Reboot. Notes for the 7zip method - I used the fastest compression (mx=1). For 70GB data, this took only 3.5 hours using ZIP compression but about seven hours using 7Z compression. ZIP files amounted to 42.5Gb, while 7Z amounted to 39GB. - For reason unknown, when extracting from the ZIP archive, the folder dates are - for some folders - set to the date of extraction, not the date the folder was originally created, although viewing the archive in 7zip file manager does show that the folder creation date is recorded. Having perused the SourceForge 7Zip forum, this seems to be a common problem. - One nice feature of 7Zip is the ability to define an exclusion list so you can avoid archiving particular folders. You can see I have done this with xr@exclude.txt above. Conclusion My preference is the 7zip solution; the disk space consumption is considerably less than DIX and ImageX, and - using ZIP compression - backup creation time is quite low. ImageX is just way too slow for my liking. Also, its lack of on-the-fly splitting is, for me, a show stopper. DriveImage XML is a useful tool and I would recommend it to anyone looking for simple GUI based drive image backup tool. I hope this helps some people in deciding which backup method to adopt.

Hi Jaclaz - Thanks for the links! Indeed; I wouldn't want it to image the entire disk, just the drives on the disk that I specify. ODIN looks particularly promising. Looks like development ceased on that one. It looks kinda similar to ODIN. Yep, I came across that thread too. It started to lose its focus, though. And the bit about the licence - well, I don't really want to go there.

Hi Tripredacus - Thanks for your reply. Surely then it wouldn't serve its purpose (i.e. creating system images), no? If I merely want to back up my own data (photos, mp3s, docs etc), then I could use one of an array of tools from MS SyncToy thru to simply manually copying files/folders onto an external drive. Okay, I'll give it a go next week and report back. Okay - this doesn't inspire me with confidence. I guess the key thing is to have a tool that will reliably restore a working and bootable system, so if I'm not confident ImageX can provide this, I'll veer towards using DriveImage XML.

I've been researching disk imaging/cloning tools for the purpose of creating a one-time backup image of my C:\ drive, for use in the event of a hard drive failure. My system is XP Professional SP3. I've used BartPE many times in the past; this is my favoured maintenance environment. I recently came across ImageX - part of the Automated Installation Kit - which looks potentially very useful in this scenario. It is file-based rather than sector-based, meaning I don't have to worry about the partition size prior to a restore. It is also a command line tool, apparently fast and has a high compresion ratio, all of which appeal to me. I was thinking of using the following to backup: imagex /capture source: dest:\XP_backup.wim "Windows XP Professional" /compress maximum And to restore on a partitioned and formatted drive: imagex /apply source:\XP_backup.wim 1 dest: bootsect /nt52 dest: (last line to restore an XP boot sector) Can anyone see any problems with my proposed method? I've since come across a number of posts which suggest that ImageX should not be used as a backup tool, and one which - although specifically targetted at Vista users (which I am not) - worries me slightly: You cannot use the ImageX.exe tool as a backup tool on a Windows Vista-based computer http://support.microsoft.com/kb/935467 The following are the issues when you use the ImageX.exe tool as a backup mechanism: * Extended attributes are lost. * The ImageX.exe tool only applies reparse points that are symbolic links or junctions. * Sparse files on the system are captured and applied. However, the sparse files are no longer sparse after they have been applied. * Object IDs on files are lost in the capture process or in the apply process. This article strikes me as slightly odd, given that ImageX was released for Vista. Presumably these issues also apply to Windows 7 users? It says here that the ImageX tool and the format are unchanged for Server 2008 AIK, so if this is the case - with no "fix" for these issues in the latest imagex.exe - one would surmise Windows 7 users are also affected. How much of a practical issue is this for home users? Are these non-capturable NTFS features particular to just Vista/7? I see these limitations are also documented on Technet, under Limitations of ImageX. It's tempting to forget ImageX altogether and use a purpose built tool such as DriveImage XML. What other (free) tools do folk use to backup their systems? Thanks in advance!

@cluberti: Thanks, that certainly makes things clearer. I'm still confused by a particular clause in MS's original EULA, though: To me this makes no sense. If you're not supplied with backup media by the manufacturer, then how is one supposed to make a backup? I guess you could buy Symantec Ghost or similar and take a backup that way, or borrow a friend's XP disc and back that up. What are MS implying?

@Ponch. Thank you for your reply. The computer is licenced to run Windows XP Home OEM, therefore I can legally transfer the computer (which includes the hard drive with legit Win XP on) + licence to a third party; that much I know is correct and in accordance with the terms of the XP OEM EULA. I am talking specifically about the installation media. I would not be looking to profit from providing a CD-R; simply providing the means to restore the O/S if need be. I would have thought that Microsoft would not be concerned about the media used to conduct the install as long as the licence is valid and above board.

Hypothetical scenario: I have a Dell/Compaq/Lenova computer with a genuine Windows XP Home OEM COA sticker on the side, but no recovery CD. I install Windows XP Home using a generic, non-targeted, OEM CD - which happens to be a burnt CD-R from an untouched original CD - and activate it using the key on the COA sticker. If I choose to sell the computer on the second hand market, am I allowed - within the terms of the EULA - to provide the buyer with a copy of the burnt CD-R of Windows XP Home OEM, in case the buyer needs to reinstall Windows, say because of hard drive failure?

Polymorphean Great tip for the setup.exe /z-w switches. All works for me. I have a Connect3D Radeon 9500 NP, and was a little disappointed to discover I couldn't install the ATI DVD Decoder, even tho I have the original CD - I'm guessing it was because I have an OEM version of the card. Now I can make the most of the Adaptive de-interlacing that's built-in, primarily for experimenting with AVISynth stuff. Anyway, I created my own little batch file to automate the process of installing from setup.exe. Simply paste into notepad, save as a *.bat file and run from the same folder as setup.exe. I found that it didn't matter where you create your fakecd directory tree (can be many levels deep) and that you can spoof the files it looks for. I'd be interested to hear if this works for folks: [font="System"]@ECHO OFF setlocal enableextensions pushd %CD% mkdir fakecd\BIN cd fakecd SET schwing=%CD% mkdir install\DVDDcdr cd bin echo fakefile > aticdfp.sys cd ..\install\DVDDcdr echo fakefile > DVDDcdr.dat popd start /WAIT Setup.exe /z-w"%schwing%" IF EXIST fakecd rd /S /Q fakecd endlocal[/font] Regarding that stupid atiCDwiz.exe file that ATI tricked me into thinking is the actual installer, you can easily get round the CD check with a little tool called [url="http://www.securitysoftware.cc/apps.html"]Enabler[/url]. Quite honestly, I don't know why they bother with such checks, when programs like Media Player Classic (with in-built filters) are freely available and the quality difference may be negligible, depending on your graphics card. Anyway, for completeness, here's how I did it: Simply insert any old CD, point it at that CD and click Next. Click ok when it say "Valid ATI CD not found". Then run enabler, double click on ATI CD Wizard Page 2 of 4, look for where it says &Next and right-click that, then left click Enable. The enable button will no longer be greyed out, and you can progress to download setup.exe.