HSR - displaying ready, but not caught up


SETUP:  I have a setup that replicates images offsite to a backup qnap NAS using iFTP.  The NAS has a VM that is running image manager which verifies, retention, and consolidation.

Also, I have a DR server which reads those same images using another local Image Manager - this image manager’s only task is to create a VM image file via HSR for each server and verification which it has to do as part of the process.

The server is usually turned off – then turned on every so often to get the latest images, complete the HSR job to the current point in time, and then when complete, I turn it off.  So in the event of a disaster - the server images are good to go, whichin a few days.

ISSUE:  IM can see all of the files and verifies them, however the HSR jobs sometimes get stuck and show “ready” but is a day or 2 old.  The only way to fix the issue, is to delete and recreate the HSR job.

The HSR job says ready of say "18/05/2016" (just realized 2016!) - the date modified on the vhdx file is "11/04/2017"




Tried:  Everything is up to date, stopping and starting service, pause and start job.. etc


UPDATE:  It's very clear that the image manager has no connection with the files at all - the job is there, but that is about it.



Complicated setup.

If you have a DR server why don't you just use the virtual boot technology. In the event of a disaster just VB the server then recover at will....

Server will be up much quicker and to the latest backup point.

This will also allow you to use the advanced verification function ;)


Backup & Disaster Recovery in the UK.


Virtual Boot - not working?

Thanks very much for your input, I was thinking not one was reading these threads.

I did a bit of research and gave Virtual Boot a try - it would seem to automate the process if it all worked correctly.  And it's not just one server, it's 3 production servers that all work togther. Exchange, databases, Domain controller, etc

Virtual Boot - Results

  • I tried booting a machine and the first error I recieved that all of the images have to be in the same folder
  •   - this is a bit stilly as each partition is in a sub folder and required for production (would have to restructure)
  • I next tried to boot another machine that does have 2 partition in the same folder
  •   - This machine, although both C and D were selected, only C was actually created and placed into Hyperv
  •   - This machine is twirling at the Windows Server loading page and hasn't gone any further (will tell you if it boots)

Am I understanding this wrong, or do you have any suggestions?

Where is Shadow Protect support?


Thanks James


Optimal backup job

Optimal backup job configuration is to include all critical volumes in the same continuous incremental backup job.  Configure each machine to backup to it's own managed folder so multiple volume images are all in the same place.  Manage the folder with ImageManager and keep it running all the time, because the more optimized your chain is, the faster you can restore.  Here's a link to the SPX Windows Quick Start.

If different volumes are in different jobs then all critical volumes including server databases and applications are not being backed up in the same snapshot at the same time.  This means the system information from different image timestamps can be out of sync.  When database and application volumes get restored to slightly different points-in-time unexpected system issues and database errors can cause a bigger problem getting things running after restore or VirtualBoot.  Unless VirtualBoot is misconfigured, this testing and recovery tool that is telling you that you have a configuration or system issue that needs to be addressed before there is a disaster and recovery needed.  For best System Recovery results restore all critical volumes to the same incremental image timestamp all contained in the same job.

Without examining your mostly turned off ImageManager HSR machine replication issue, I don't know exactly what went wrong, but my best guess is that there is an issue from the sending ImageManager machine images getting received and verified by the turned off machine, and if it hasn't received all of the images in order that it needs to maintain the HSR chain, then offsite/2nd ImageManager chain has become out of sync.  To get more details about what is happening, look at the Logs folder under Program Files (x86)\StorageCraft\ImageManager.  I recommend checking out this article:  https://www.storagecraft.com/support/kb/article/283

If you need further assistance from our support team, click on the Request Help button on the menu above, there is a link to our latest diagnostics utility, so to speed up the investigation include the diagnostics results from the machine having the issue (start with the ImageManager machine that is sending the images to the HSR ImageManager machine, but they might end up needing to look at both machine's diagnostics).



Thanks for your help Nephi, I'll try and explain.

Here in Australia, we are told over and over to have different jobs for each partition.  In the event that a job fails, it won't stop the other partitions from being backed up - this if from Jack the main ST man.

I have also read in SP notes that it's not uncommon for different Image Managers to do difffernet things with retention and consolidation, and this isn't a problem. The ftp replication is only sending the daily unconsolidated files.

The main ONSITE IM is always on and it is always fine - then there is a second OFFSITE IM running on a VM NAS (windows 7) and that is also always ok.  The turned off IM on server 2012 is the last portion of the backup setup and it uses the SAME images file shares that the NAS (windows 7) box uses.  So ONSITE machines backs up - IM1 sends those images offsite to IM2, and then a IM3 turns on reverifies the images and creates the HSR (that is it's only job).

Everthing ususally works, for months, but every so often it will say the job is fine (which I assume would mean the log would say ok) but it isn't actually doing anything.  I would create a HSR job on the NAS (IM2), but it doesn't have the capasity or hardware ability I belive.

The thing with Virtual boot is that it doesn't boot the whole machine (or it didn't in my tests) but only the boot partition - should it work differently?  IT also only uses IDE not SCSI and Generation 1 not  2.  There seems to be very little documenation on VM boot.


I am in the process of ditching the NAS, and just having a backup server which can also be used as the DR server.


Thanks for you help, and any suggestions you may have.






When all volumes are part of

When all volumes are part of the same continuous incremental job, in ShadowProtect 5 you can right-click on an image file in Windows Explorer and the VirtualBoot wizard will include all volumes that are part of that backup job.  This functionality has recently been added to SPX 6.5.x but I don't have a machine with multiple volumes currently so I haven't tested if it attaches all volumes yet.  It will always show you what volumes have been included and give you the option to add or change things with the volumes selected.

But when the volumes are part of seperate jobs then you will need to add the additional volume images during the VirtualBoot wizard if the system depends on them.

For example, let's say you are backing up a SBS 2012 server that has Windows on C:\, AD and Exchange databases on D:\ and Transaction Logs on E:\.  All of those volumes should be included in the same backup job.  Exchange VSS doesn't recognize it as a proper backup unless all critical volumes are in the same snapshot request.  If those volumes are being backed up at different times, then what happens when you restore C: to 3:00PM D: to 3:05PM and E: to 3:30PM?  Things will get wacky.

In my opinion the only reason for seperating out the volumes from a single backup job would be for troubleshooting on a server that is having other performance and operational issues.  Look to the event logs and what system services are complaining search google for answers, and optimize the server performance settings.  But having multiple backup operations instead of 1 program and 1 job managing things could be the cause of things colliding and causing more issues in the background.  I've experienced it myself trying to backup 1 volume with 2 different jobs on a machine, you have to make sure they don't try to run at the same time.

Good luck!

Terms and Conditions of Use - Privacy Policy - Cookies