My "Nom de Guerre" is getting bantered around in this thread a bit... as such, I must jump right in. When I refer to potential unreliability as it relates to AX64... it comes from two sources. The first is my personal experience with the product, which having generally been quite good, has had its issues along the way when using both HOT restores and WARM restores. In discussing these issues with the TM Development Team, they have also determined, through their own testing, that "issues" do exist with both the HOT and WARM restore methods, and the only way to eliminate them will most likely require a redesign of the restoration operation. Sure, many users have had good luck in using this application, but I must point out that it truly has been LUCK, especially in the factual realization that design issues do exist. Their suggestion for a possible redesign points to a re-writing of the restoration process to run at a pre-BOOT point in the Windows loading process known as Native App. This point in the process has basic access to most of the storage devices on the system and appx.(25) documented "Native Mode" API (Application Programmimg Interface) calls to do the job... there are actually about (250) API calls available at this point but MicroSloth has chosen not to document them for public use in order to protect their right to change them at will. At this point in the process, Windows has yet to be started and absolutely nothing is running yet... a very safe time to be reconstructing File Systems. This is the same place in the BOOTing process that "ChkDsk" and many BOOT time defrag processes run. Programming at this level of the OS is a bit more difficult than normal programming languages using standard assemblers/compilers but it is very doable. If the AX64 Devs take this approach, I wish them all the best... it probably will be the only way to provide for a "guaranteed" trouble-free result.