ShadowProtect supports only incrementals for one backup job.  This allows us to take the fastest incrementals possible, but the tradeoff is that it is only available for one backup job.  Other jobs can do full backups only.

We generally recommend that if you want backups on multiple disks that instead of burdening the computer with multiple backups that you copy the original backups instead to the alternate disk.  You may have to create a schedule that is better suited for this.

Admin

 Is there a technical reason for only supporting incrementals for a single job because I would've thought that it's simply a matter of having different sector maps for each backup job (in some cases) ?

 While having multiple incremental backup jobs would cause a slowdown (due to having to search/update multiple sector maps), it would offer greater flexibility, while surely remaining just as fast when there is only a single incremental backup job.

Internally we call this functionality "multi snap" and in fact our snapshot driver (stcvsm.sys) has the capability to do this, however, for various reasons, we have so far chosen not to expose this capability in the product itself.  Don't count on this showing up as a feature in a future release.

May i sugest that you use a post backup command to call a RoboCopy script that will copy the internal disk to the USB disk and keep this disk in the exact state (replica) of the internal disk.

This is how i would do this ;-

Download RoboCopy from Microsoft and copy into the System32 directory then in the C:\Program Files\Storagecraft\Shadowprotect\ directory create a text file. Copy and Paste the following into the text file and save then rename to copy.cmd.

This is the code "robocopy.exe F:\data G:\data /COPY:DAT /E /V /PURGE /ZB" let us assume that the "F:" drive is the internal drive with the backups being stored in the data directory and that the "G:" drive is the USB. this simple script will keep the "G:" drive as a perfect replica of the "F:" drive.

Hi Jack,

I have used the Robocopy method as outlined in your Best Practices document. As you now, the Robocopy script is run as a post command after each backup. I'm running into a problem when Robocopy doesn't have sufficient time to complete it's copy operations before the next backup completes. This usually occurs when the backup USB drive is swapped as usually one or more full backups need to be copied to the new drive, taking several hours perhaps. Now if the backups are happening every 15 minutes, we end up with multiple instances of Robocopy running. Each instance wants to copy all the full backup files to the USB drive (as no instance has completed this task yet). I have seen up to 17 instances of Robocopy running simultaneously, each in turn, copying the same 60GB full back up file to the USB drive. Usually, the task is never completed.

 A possible solution would be to ensure that Robocopy only runs if no other instance of Robocopy is running. This might mean that incrementals are not being copied for an hour or two while large full backups are being transferred but it would prevent multiple Robocopy instances from bogging down the server. Any thoughts on this?