Saturday, May 31, 2008

5-28-08

To get a RAID, Inc. Condor 12-bay RAID array to recognize new Western Digital WD2500JB drives, the jumper must be removed - setting the drive to "Single or Master". No other jumper setting will work.

32-bit operating systems will only recognize 2TB drives. An array larger than that requires a 64-bit OS.

Saturday, May 17, 2008

5-17-08

You can turn “Show all formatting marks” on in Microsoft Word & Outlook by hitting Ctrl+Shift+8,. Occassionally, people turn this on accidentally so I’m guessing what happens is that they are trying to type an asterisk (Shift+8) & catch the Ctrl key at the same time. Ctrl+Shift+8 will turn it back off again. The other way to turn this feature on & off is to go to Tools-Options in Word (you must open a new e-mail first in Outlook to do this), then on the View tab uncheck "All" in the Formatting Marks section.

BTW, Ctrl+Shift+l (the letter l) will start a bullet point list. Ctrl+Alt+l will start a numbered list. The bullet list will continue each time you press the Enter key, back the numbered list requires another Ctrl+Shift+l to get the next number in the sequence.

Monday, May 12, 2008

5-12-08

Source:

“That being said, yes, you're correct, I'm one of the senior engineers at StorageCraft. I was also one of the core engineers who developed DriveImage/Ghost.”


From http://www.wilderssecurity.com/showthread.php?t=139716&page=11

It's fairly important to determine your exact needs before selecting a backup solution. Home users who don't care about disaster recovery have many free backup options. Technical home users can cobble together enough free stuff to make a passable backup/disaster-recovery solution. Enterprises, generally, need to be far more cautious about the software they place on their servers, and should carefully evaluate the software for stability (does it deadlock your system? do its services hang or crash? do its device drivers cause blue screens or do they have any interop issues with other drivers?), data integrity (are the back up image files good even after thousands of incrementals and splits? does it corrupt original data?) performance (does it use a lot of memory, leak memory, hog CPU or interrupt any applications?), security (does it protect your data? How are its APIs guarded?), and maintenance (is it automated, scriptable, can it be controlled remotely, can one console GUI control an entire enterprise, etc). If you are an enterprise customer, or a very discriminating customer, it would be advisable to ask the backup solution vendor these pointed questions and do your own due diligence as well.A side note: If you are evaluating criteria like the above, in relation to memory leaking you will find that the Microsoft Volume Shadow Copy Service (VSS) on Windows XP has some bugs that will cause VSS requestor processes (VSS-aware backup applications) to leak memory on each snap/unsnap cycle. Also, on XP, on each snap/unsnap cycle the vssvc.exe service as well as a dllhost.exe process will leak a little memory. This is usually only an issue if you use a VSS-compliant backup application to automatically backup your data on regular intervals over a long period of time. These same leaks used to also occur on Windows Server 2003 however they have been fixed in a recent private (you must request it, KB923628, directly from MS support) hotfix for Windows Server 2003 only.If you are an enterprise or extremely-discriminating user, the following may prove useful.First let me warn you that I'm a bit biased on this topic (I'm an engineer who has worked on core components for a couple of the mainstream backup/disaster-recovery products out there, from competing companies). Also, my experience on this topic is limited to the Windows platforms.I would recommend that you consider backup solutions that enable you to quickly recovery individual files, as well as to quickly recover from a full system meltdown (ie. a hard disk crash). In my mind there are currently only three products which can do this with any degree of reliability. They are (in no particular order):1) Symantec's Ghost (for Desktops) and LiveState Recovery (for Servers)2) StorageCraft's ShadowProtect3) Acronis' True ImageThese three products share several similar traits. They all create backup images files which represent the entire state of a logical volume's data, rather than backing up individual files themselves. This enables you to perform full volume restoration should a disaster occur, such as a hard drive failure. They also enable you to easily restore individual files by allowing you to mount/browse into the contents of a backup image file. They allow you to backup your volumes in a hot/in-use state, so you do not need to stop any of your work or close any of your applications when the backup is performed. They allow you to set up a backup schedule so that the backups are automated and no user intervention is required to ensure that backups are occurring. They allow you to perform "incremental backups" which means that when a backup occurs, it will only backup the changes which occurred since the previous backup. They all provide a bootable "recovery environment" CD which contains a bootable OS as well as tools that can be used to restore/recovery files and/or full volumes in the event that you are restoring to a machine which doesn't contain an OS, or if you are restoring an image file over your existing OS. They are all "enterprise ready" as they allow you to remotely manage large networks from one GUI console, contain scripting support, and are integrated with platform technologies (such as Microsoft's Volume Shadow Copy Service - more detail below).I'll discuss how these products differ in their offerings of these features.Hot Backups: This is probably the most important aspect of these products because this feature allows you to backup your machine with zero down time. You don't (at least you shouldn't - keep on reading) need to stop any of your applications in order to capture a good clean backup. This feature is made possible by a sophisticated "snapshot" device driver which can instantly capture the state of a logical volume at a specified time and expose this captured state to the backup software. Although Windows XP and 2003 ship with a built-in snapshot device driver (volsnap.sys), it is somewhat lacking in features (especially on XP) and alltogether absent on Windows 2000. Therefore all of these products give preference to a proprietary snapshot device driver. The snapshot device driver used in Symantec's products is licensed to Symantec from StorageCraft (see the copyright file properties of pqv2i.sys or symsnap.sys). StorageCraft of course uses its own snapshot device driver (albeit a newer and better version) in ShadowProtect. Acronis also has its own snapshot device driver. There is a significant difference between the StorageCraft snapshot device driver and the Acronis device driver which results in a substantial difference in performance when incremental backups are created. StorageCraft's snapshot device driver is far more efficient and fast. This can be easily reproduce by creating a backup job and performing changes to many files after the first full backup and before an incremental backup. In this sense, Acronis is more of a desktop product as it simply consumes too much CPU and I/O bandwidth when taking incrementals which is less desireable on servers.Scheduled Backups: The schedulers for these three products are very similar. One of the main differences is how frequently they allow you to backup your drives. Symantec's products allow you to backup a volume once every hour. StorageCraft's produt allows you to schedule a backup to occur once every 15 minutes, however the schedule can be modified so that the backup will occur once every minute (which is possible because of StorageCraft's highly-optimized incremental imaging technology). Acronis' products allow you to schedule backups to occur on a volume once per day. Symantec and Acronis allow you to backup to CD or DVD. StorageCraft's solution does not currently support backup directly to optical media. Acronis users report many issues when they backup to optical media if the backup requires more than one disk (so called "spanned images"). Symantec's backup to optical media appears to be solid.Platform Integration (VSS): Microsoft provides a framework called the "Volume Shadow Copy Service" (VSS) to assist in the creation of clean backups. This service can be used by backup products (called "VSS Requestors"), as well as by applications (called "VSS writers), which create data (such as Exchange, SQL Server, etc). When a backup product requests a backup, it can tell VSS to "quiesce" these VSS-aware applications. This will cause these applications to perform a quick flush of their critical data, without interrupting anything, so that the snapshot device driver will capture their data in its optimal state. Interacting properly with VSS is critical to performing a good quality backup and if you are an enterprise customer you really need to give this particular issue some weight. Symantec's online knowledge base indicates that you must take down your Exchange server in order to successfully backup its data. StorageCraft and Acronis allow you to backup your Exchange server without taking it down. VSS-aware snapshot device drivers which provide snapshots of volumes to backup software are called "VSS Software Providers" and of the three products only StorageCraft's snapshot device driver is a true VSS Software Provider. Neither Symantec's nor Acronis' device driver is a VSS software provider. You can verify this by installing these three products and then typing the command: C:\> vssadmin list providers You will see Microsoft's system provider "volsnap" as well as StorageCraft's VSS software provider.File Recovery (Mounting/Browsing Image File Contents): When a backup is taken, an "image file" is created, which contains the data necessary to represent the contents of a volume at a given time. An incremental image file is dependent upon the data in the previous incremental image file, and this dependency chain run all the way back to the first full/base image file created for a particular volume. This first (full/base) image file usually contains all in-use sectors so it is generally very large. All of these products allow you to compress and/or encrypt these image files. In order to allow users to restore individual files from a backup image, all of these products allow you to "mount" your backup images as virtual drives. Symantec's products also ship with a secondary "image file browser" application which allows for browsing without mounting. There are subtle differences in the mounters. All of these mounters allow you to make changes to the mounted image, but only the StorageCraft and Acronis mounters allow you to save your changes. StorageCraft's mounter allows you to mount to both drive letters and to specified directories (called "mount points") so you are not limited to 26 concurrent mounts. Symantec's mounter, like its image browser, is rather resource-hungry (uses a lot of memory) and is simply incapable of mounting multiple terabyte-sized volumes concurrently. I don't have benchmarks on terabyte-image mounting for Acronis StorageCraft's mounter allows you to mount *hundreds* of terabyte-sized volumes concurrently. This can be easily done by creating a full image, and then many incremental images with modified data, of a particular terabyte-sized volume, then mounting the full and all of the incremental images concurrently. Each mount should present a full terrabyte-sized volume. Large volume support is critical to the enterprise, and is becoming more common on desktops as well.Disaster Recovery: To recover from a disaster, where no OS exists on your machine, or to restore an image over your existing OS, or to restore an existing image to a bare machine (one whose hard drive is blank - this is called "Bare Metal Recovery/Restore"), you must be able to boot some OS under which the recovery software can run and have access to the backup image file(s) and to the hard disk controller and hard drive to which you wish to restore the image. Acronis uses a bootable recovery CD based on Linux. StorageCraft and Symantec both use a bootable recovery CD based on Windows. In my opinion, the Windows-based recovery environments are superior for Windows imaging products because they contain a larger set of device drivers on the CD for greater device coverage. This means that you are more likely to be able to access your backup images from your network, media, or USB device, and to be able to see and access the drive to which you wish to restore the image, using a Windows-based recovery environment than you are with a Linux-based recovery environment. It's very important that you test the recovery environment BEFORE a disaster occurs to ensure that it can see your drives and the location on which you're saving your backups. The StorageCraft and Symantec Recovery environments are very similar. StorageCraft provides some useful options which are not available from Symantec. For instance, StorageCraft's recovery environment, at the start of its boot, allows you to choose if you wish to boot with the minimum or maximum driver configuration. If you don't need to access exotic drive or network devices, the minimum configuration is usually sufficient and boots much faster (usually around 2-3 minutes faster). For the enterprise-conscious user, both StorageCraft and Symantec ship their recovery environment with a tool that allows a remote administrator to manage the recovery environment, however this tool is free of cost from StorageCraft yet quite expensive from Symantec. Acronis and Symantec advertise that they allow you to restore an image to a different machine (aka "Universal Restore"), however in my experience I have been disappointed by this feature in both of these products as I have *never once* succeeded in restoring to a different machine (in many test cases) using LiveState or True Image. Acronis and Symantec will allow you to restore an image to a volume which is smaller than the volume that was used to create the image. A typical user will create one big primary partition that consumes their entire disk. For these typical users, if they plan to restore to a hard drive that is smaller than their original drive, then this feature is an important point to consider.Deployment: The installation experience for these products is very different from one to the next. For the enterprise user, Acronis' enterprise product actually consists of several separate (and unintegrated) product installations. This is an akward and time consuming affair. Acronis's install is not dependent on the .NET framework. StorageCraft's install is a single installation file which contain all features, fully integrated (the total installer size is 9MB). StorageCraft's install is not dependent on the .NET Framework. Symantec's installer is a single install as well, however it does depends on the .NET framework, and therefore can be quite lengthy and consume a good deal of disk space.None of these products are perfect, and like I said, I'm biased, so play it safe and evaluate them all.
Last edited by grnxnm : September 2nd, 2006 at 12:28 AM.


Quote:
Which, if any, of these will work with my RAID array as my only hard drive?

When installing Windows, you need to install a driver for it (the F6 option) -- an Intel ICH7R. Obviously, for anything that runs while Windows is running, access to the drive is not an issue. I'm concerned primarily about the restore case -- with separate boot floppies/CDs/partitions, will I have a driver available to access the RAID array? I used to use Ghost 9 but gave up with Ghost 10 for all of the reasons I've seen expressed by others. So, I'm looking for a replacement product.
In the Windows world, your best bet (IMHO) at gaining access to your RAID drive(s) from the recovery environment is to use a recovery environment which has the greatest device coverage, hence one which is based on Windows itself. Both ShadowProtect and Ghost/LiveState ship with recovery environments (bootable CDs) which are based on Windows. When you boot the recovery CD of these products, you will have the option to press F6 and feed in your miniport diskette. Often though you'll find that, for the more common host bus adapters, the miniport device driver for your adapter is already included on the recovery CD and is automatically loaded when the CD boots. If you intend to use your backup product for quick disaster recovery (to quickly recovery your system boot volume), then it is critical that you first ensure that the recovery environment of your chosen product is capable of accessing both the drives/media/network resources on which your backup images are stored as well as the drive(s) to which you will be restoring images. Acronis True Image has a recovery environment which is based on Linux, and this can cause problems when you attempt to access certain devices. Windows-based recovery environments are better, and hence the easiest solution for this issue is ShadowProtect or Ghost/LiveState. For enterprise (corporate) customers there are additional incentives for using a Windows-based recovery CD. For instance, Windows automatically supports Dynamic Volumes. Trusting that some non-Windows recovery environment properly supports dynamic volumes, especially as the structures that define them (licensed from Veritas to Microsoft) are all proprietary and undisclosed, is a stretch.


From http://www.wilderssecurity.com/showthread.php?t=139716&page=12


Quote:
It was my understanding that image based backups locked the drive currently being backed up.

Oh, I see. This is true for older generation backup products, which do not incorporate snapshot technology. However, latest-generation image-based backup applications usually employ snapshot technology, and the sole purpose of snapshot technology is to enable the backup application to capture the state of the volume at a point-in-time without the need to lock the volume or stop any of the applications that are using files on the volume.Maybe it would be useful to the forum to describe exactly what "snapshot technology" is. The goal of snapshot technology is to instantaneously capture all of the data on a volume at a given point in time without interrupting I/O to that volume (without locking anything, stopping applications, etc). This is invariably implemented using an "upper volume class filter device driver" which intercepts I/O underneath the file system, but above the volume devices (see the storage stack diagram below). When the snapshot device driver is instructed by the backup application to establish a snapshot of a given volume, it immediately starts tracking changes that occur to that volume. Each time a write occurs on the volume the snapshot driver first copies off the old data that was already at the location into some scratch pad area and then allows the new write operation to continue on down to the device. Thanks to this copy-on-write mechanism, the snapshot driver is able to preserve all of the information necessary to expose to a backup application the data that was on a volume at a given point in time. Snapshot drivers usually expose the snapshot point-in-time by creating a virtual device similar to a volume device. The backup application will read the sectors on this virtual device in the same way that it would have read them from the real volume. The backup application *may* lock access to this virtual snapshot device, but keep in mind that this virtual device is generally only used by the backup application (it's not visible to normal applications). Locking the virtual snapshot device has no effect on the actual volume device that is being backed up - the real device is never locked and remains accessible to applications. Because snapshot device drivers sit within the storage stack itself, they have absolute control of the flow of I/O to the disk. When a snapshot driver is instructed to establish a snapshot, it takes only a few microseconds, if not less time, for it to halt I/O to the device and establish the necessary in-memory structures necessary to maintain mappings of which sectors have been changed (causing copy-on-write operations) since the establishment of the snapshot, and then to allow I/O to recommence. It's important to understand that there is a difference between the act of "taking a snapshot" and the act of "imaging the data on a snapshot". Taking a snapshot requires only a few microseconds, if not less time. Imaging the snapshot is the process of backing up all of the data that are exposed by the snapshot device driver for a particular point-in-time (usually exposed as I mentioned by a virtual volume device), which is all of the data on the drive at a given point in time, and this can be a lenghty process. When a plain-vanilla snapshot device driver creates a snapshot of a volume, it is instantaneously capturing the volume's state at a given time, and the state of the volume's data is very similar to the state of its data if you kill the power to the computer. This is called a "crash consistent" state. The reason for this is that, at any given time, many files are open and in use and also the file system itself can have structures which are write-cached and have not yet been flushed. Creating a plain-vanilla snapshot captures the data in this in-use state, so it's not a very clean snapshot (it's "crash consistent"). VSS was introduced with Windows XP, and one of its primary purposes is to facilitate the establishment of snapshots when the data is in a clean state. To do this, backup applications and snapshot drivers must be written to interact with VSS. VSS controls the snapshotting process. The backup application will ask VSS to take a snapshot, using a specified snapshot "provider" (snapshot device driver). VSS will then tell all VSS-aware "writers" (applications which generate data such as Exchange, Oracle, SQL, IIS, and many system services such as the registry, etc) to quiesce (meaning that these applications flush their files to disk in a state that is clean and then pause for a small moment until they are told to resume activity) and then VSS will send a special flush-and-hold message (IOCTL) to the file sytem on the volume on which the snapshot is being established and when the file system receives this flush-and-hold message it will flush all of its metadata to disk and it will then send this flush-and-hold message further down the stack and the file system will not send any more I/O down the stack until the flush-and-hold IOCTL is completed by the snapshot driver which resides below it (which establishes an I/O barrier at the file system level). When the snapshot driver receives the flush-and-hold IOCTL, it knows that all VSS-aware applications as well as the file system itself have flushed their data in a clean state, so it establishes the snapshot and then completes the flush-and-hold IOCTL, which completion event is then received by the file system driver above it at which point the file system driver releases I/O and passes the completed flush-and-hold IOCTL back to the VSS service, which then releases all of the VSS-aware applications. Through this mechanism, VSS-compliant backup software, which use VSS-compliant providers, can create backups of extremely high-load Exchange, Oracle, IIS, SQL, etc. servers on a regular basis without the need to stop any services or applications, without shutting down the machine, while also ensuring that the backups contain good clean data (databases will not need to be fixed/repaired if they are restored, because VSS ensures that they are captured in a good state).On platforms older than XP, where VSS is not present, other techniques are used to obtain images which are better than crash consistent state images. For instance, some snapshot drivers implements their own I/O barrier at the file system level (using a file system filter driver), if necessary, and on platforms that lack VSS (Windows NT and 2000) the driver is capable of performing the file system flush-and-hold operation which is natively supported on XP+. This enables it to perform snapshots at a time when the file system's metadata has been flushed to disk. Coupled with this is a more manual quiescense process which is facilitated by the backup application itself, which enables users to specify scripts which they wish to be called before and after the establishment of the snapshot, which scripts can be used to stop/start services, etc (or in other words, the scripts are a way of quiescing important applications). While this is more tedious, it gives users of older platforms, that lack VSS, some of the advantages of VSS.Windows Storage StackI/O within the Windows kernel flows from one driver to the next until it is finally passed directly to the hardware device. Each type of device typically has several layers of drivers that manage I/O as it flows to the device. For storage, I/O generally is initiated in user mode (from applications) and is passed to the kernel's I/O manager where it then forwarded to the appropriate file system driver, then to the volume class driver, then to the disk driver, and finally to the storage controller port driver. Filters can be added at any level in this stack.

----------------------
Win32 Application(s)
----------------------

-----------------
Win32 Subsystem
-----------------

---------------
Native NT API
---------------

-------------
I/O Manager
-------------

--------------------
File System Filter
Driver(s) such as
AntiVirus Drivers
--------------------

--------------------
File System Driver
such as NTFS.SYS
--------------------

--------------------
Volume Filter
Driver(s) such as
Snapshot Driver
--------------------

-----------------
Volume Driver
-----------------

-------------------
Filter Driver(s)
-------------------

---------------
Disk Driver
---------------

-------------------
Filter Driver(s)
-------------------

--------------------
Port and Miniport
--------------------

-------------------
Actual hardware
device
-------------------


Quote:
And changes on one volume are related to changes on other volumes, e.g., due to registry references to other volumes.

I'm glad you brought that up! In fact, this specific scenario (where dependent data is spread across multiple volumes) is specifically addressed by the VSS framework, and mechanisms are in place within VSS to ensure that interdependent multi-volume data can all be flushed simultaneously and all captured in a clean state, without interrupting application services.


From http://www.wilderssecurity.com/showthread.php?t=139716&page=13


Any sector-based imaging product that supports incremental imaging will generate very large incrementals if you defrag a volume in between backups.


From http://www.wilderssecurity.com/showthread.php?t=139716&page=15


A side note: You mentioned "Drive Snapshot". While this product may work just fine for the home user, I would advise the Enterprise user to use caution if they are considering adopting it as a solution. Drive Snapshot employs what is generally considered to be a dangerous technique (dispatch table hooking) which enables it to dynamically insert its volume filters into the storage stack. The net effect is that Drive Snapshot can install without the need to reboot, however the cost is that it employs this risky (and frowned upon) technique. Ask anyone in the main driver development forums (OSR's NTDEV and NTFSD email lists) or any of the DDK team at Microsoft what they think of dispatch table hooking in an enterprise solution and you'll find that it's not advisable. Just do your due diligence - test the heck out of it and especially do interop testing with other volume filter drivers. Who knows, perhaps Tom Ehlert's dispatch table hook is solid. It's a cool trick, that's for sure.

ShadowProtect doesn't modify the MBR in order to operate. ShadowProtect will always back up the MBR, as well as the entire first track, each time a backup is made. It's important that not only the MBR be backed up, but all 63 sectors of the first track need to be backed up, because products that inject boot loader code into the MBR often also inject code/data into the additional "hidden sectors" of the first track on the disk. If you backup and restore only the MBR, there's the possibility that you have restored only a portion of a boot-loader-injected app. To be safe, you must back up and restore the entire first track, including the MBR. However, if you have a standard MBR, with no injected boot-loader code, then there's no need to restore the MBR or any of the hidden sectors at restore time.A note on MBR restoration - a portion of the MBR is of course the partition table itself. The rest of the MBR sector is executable code. When we restore the MBR, we of course do not destroy the existing partition table, but rather we restore the CODE portion of the MBR.At restore time, ShadowProtect will allow you to choose between these options:1) not do anything to the existing MBR and hidden sectors2) restore the MBR along with the image that you're restoring3) restore the MBR AND the entire first track along with the image you're restoring4) Lay down the standard MBR along with the image you're restoring.I didn't realize that First Defense-ISR modifies the MBR in order for it to operate. This, to me, suggests that they're using an int 13h hook in order to filter disk I/O. A strange, and unnecessary, approach for a windows product. Windows itself provides a safe framework for volume filtering, which is interop-friendly. Any product that injects code into the MBR will almost certainly cause issues with other products that do the same. So, be cautious - make sure that if you use this product you never intstall some other software which also uses boot-loader code (such as a disk encryption product). It's a great recipe for very nasty interop problems.

ShadowProtect leverages Windows' own support for RAID, SCSI, USB, etc., by always running from within Windows (2000/XP/2003/WinPE), so you will have the same device support as you have from within Windows. I'm not sure what your question is about drive letter assignment, can you please clarify? As far as speed goes, we did a lot of benchmarks to ensure that our product's speed meets or beats the competition. We also did a lot of optimization to ensure that we use less (often far less) CPU and memory during our most intensive operations. Bare Metal Restore/Recovery (BMR) is of course supported using the bootable ShadowProtect Recovery Environment CD. Image sizes are only limited by the file system which contains the image files. FAT32 files can only be <= 4GB in size, so if you are backing up a large volume and storing the image on a FAT32 volume, ShadowProtect will automatically split the image into 4GB pieces (this is a so called "split image"). Also, you can instruct ShadowProtect to split the image at a particular size if you wish to later archive the split pieces to optical media (note that ShadowProtect doesn't *yet* support archiving directly to optical media). Image sizes when stored on NTFS volumes can be up to 2^64 bytes in size (truly massive). Assuming the partition is sufficient in size, you can restore an image to any partition, regardless of whether it is the active partition or not. At restore time, you can also decide if you want the partition to which you're restoring to become an active partition if it is not currently the active partition. See comments above regarding interactions with the MBR and partition table. I'm glad you mentioned the BOOT.INI - after restoring a volume, ShadowProtect parses the existing BOOT.INI file to ensure that the system is still bootable, and if the BOOT.INI is invalid it will patch the BOOT.INI so that the system will boot (and back up the original BOOT.INI). Migrating to similar hardware is not a problem. Migrating to significantly different hardware ("Restore to Anywhere") is not currently supported, however this feature will be in the next major release and is in fact 100% coded and we have been demoing it to partners (see paragraph below for more details). Speaking of "Restore to Anywhere," I'm personally very disappointed with the implemention of this feature in both Ghost/LiveState and TI, as I have never *once* successfully used this feature in either product. I hope that our solution will prove to be much more robust (I can tell you that right now, in alpha state, it's already way faster than the equivalent feature in the competitions' products, way easier to use (just check a box, no need to install anything else, works with all your older images unmodified), and already works in most of the cases we've tested it against). When I say "significantly-different" hardware, what I mean by this is:-Restoring to a machine that has a different motherboard chipset (VIA, Intel, AMD, SiS, nForce, etc).-Restoring to a machine that has a different type of interrupt controller (PIC, APIC, etc).-Restoring to a machine that supports a different number of CPUs (uni vs. multi)-Restoring to a machine that has a different storage controllerRegarding "conflicts with other running utilities", or interop issues in general, and the problems the forum members have had with other "snapshot" utilities, it may be useful to understand the pedigree of StorageCraft's snapshot device driver. All complex drivers will occasionally have interop issues. However, the more exposure your driver has, the more likely you are to discover and fix these interop issues.ShadowProtect's snapshot driver was developed by two DDK MVPs (MVPs are individuals who're globally recognized as being the most knowlegeable/helpful in a particular Microsoft-related technology - in this case these guys are world reknowned device driver developers). Our snapshot device driver is actually licensed by many companies for inclusion in their own products (Ghost, for instance, uses our snapshot driver, as does VMware, LiveVault, Dantz (in Retrospect), and a host of others). Due to its wide exposure over the years (it's been shipping in commercial products for around 5 years) and large install base (our driver is installed on literally tens of millions of computers), we've had the time and exposure necessary to shake out the vast majority of bugs.StorageCraft's core competency has always been the development of kernel mode technologies (device drivers). In fact, for many years, StorageCraft was purely a tools vendor, licensing tools to other software shops to help them to build products. Over the last 2.5 years, we've transformed into a products company. I suppose that we just got tired of watching others wrap our technologies with GUIs and make insane profits from it. We figured we could probably make a better product as we are the actual developers of the core technology itself.Rollback Rx does NOT use our snapshot driver.


From http://www.wilderssecurity.com/showthread.php?t=139716&page=16

Oh, also, I should mention that the Desktop Recovery Environment is a Windows Server 2003-flavored WinPE. This means that you need the Windows Server 2003 version of the miniport diskette for your storage controller, even if you don't use Windows Server 2003 on your actual computer. If you can't find a Server 2003 miniport diskette, then one for XP usually works.

From http://www.wilderssecurity.com/showthread.php?t=139716&page=17

I had an interesting conversation with Howard today and I thought I'd mention one thing that we discussed which may be of use to anyone who uses ShadowProtect, Ghost, True Image, or any similar product with incremental capability on a multi-OS-boot system.Typically, when you install a snapshot-based imaging product, a snapshot device driver is installed along with the product. If you're generating incremental images, then this feature is often supported by the snapshot driver which keeps track of the sectors that have changed since the previous full/incremental backup. When you shutdown your system, this change list is serialized to disk and reloaded on boot. If you boot to another OS, on which the snapshot driver is not installed, and make changes to a volume on which this "incremental tracking" is being performed, the tracking will not occur within this other OS environment, and so when you boot back to the original OS and generate a new incremental, it won't be a good incremental.So, generally speaking, follow this guideline: If you use snapshot-based incremental backup on a multi-boot system, only create full/differential images, but never incremental images. Data integrity is key.

Quote:
Does not apply to True Image.

Wow, that's very interesting! That, combined with the evidence that TI's incremental performance degrades very quickly when you make a lot of changes to your volume from one incremental to the next, strongly suggests that TI's internal implementation for their "incremental" feature is actually an abbreviated differential implementation. There are pros and cons to this. The pros are that it won't have issues with multi-boot environments. The cons are that performance will be very poor for backup jobs that perform incrementals on high-load servers. Hence the product is poorly suited for enterprise servers, but for multi-OS-boot end users it has a distinct advantage (if they want dependable (theoretically) incremental capability and also want to boot to multi OSs).

Friday, May 2, 2008

5-2-08

From the command prompt, dir /ad will show hidden files & directories

From the command prompt, once you have navigated to a folder, you can type explorer . (explorer space period) & Windows Explorer will open in that folder.