I have a device that is blue screening when IM virtual boots the latest backup file with the default VirtualBox settings. I did quite a bit of testing and found that, by giving the VM additional resouces, it resolved the issue. It would be extremely convenient to have global advanced verification setting just like retention settings in IM, and then be able to override those settings on an individual basis if needed, like my case.
So I have multiple ImageManager endpoints that are replicating to our ShadowStream server. All settings on ImageManager are essentially set to default. The setting I am most concerned about is the ShadowStream replication job Replication Mode setting. Where it asks:
"Are you replicating to a folder being consolidated by a second ImageManager?"
The default is set to "No" with the "Files moved or deleted by ImageManafer are deleted on the destination" selected.
What's the purpose of not letting us use path separator characters on a network drive location, but letting us use them for a local drive location?
I've been running into some issues with ShadowStream on a couple different sites, but I will narrow it down to one to simplify everything.
Not too long ago, I had ImageManager v7.02 setup and running without issue for 4 different devices. All being replicated through Legacy ShadowStream. (New ShadowStream server is a work in progress) Originally, everything was running fine. I was getting backups and backups were being replicated to an off-site location.
This is separate from my suggestion here:
Replication should be able to aggressively retry its operations if there is an error or failure and only alert if it determines that it can not continue. Minor hiccups will occur when you are transferring over a WAN connection, I want ImageManager to be a little more resilient towards this reality. If you agree with this follow the link above and vote on my other idea!
Now that ImageManager 7 has allowed the use of HeadStart restore and intelligentFTP to be included for free, I am sure there are a ton of IT teams that are making use of these great features. I am requesting that some additional status rules be added to ShadowControl so we can use it to monitor all of the functions that ImageManager provides. Right now it only monitors disk space, file verification, file consolidation, and service responsiveness.
It would be great if ShadowControl could also start monitoring and alerting on:
ShadowControl is fantastic as a 'single pane of glass' for monitoring and managing ShadowProtect SPX and ImageManager. However, it could be improved with regards to Advanced Verification Screenshots (AVS).
1) Report on whether ImageManager Advanced Verification is enabled or not, as well as the basic config parameters if enabled (daily/weekly/monthly, capture wait time).
2) Integrate the actual screenshots into ShadowControl GUI in some manner. A couple of ideas:
My request is to allow ShadowControl portal to have an option to flag warning/critical alerts for ImageManager inactivity. ImageManager itself is able to send email alerts, but the benefit of having it show up in our ShadowControl portal would be extremely valuable. We manage backups for 600+ servers, so a feature like this would be extremely valuable.
I am replicating roughly 30 PCs/servers off-site via intelligentFTP to a data silo in my office for a variety of different customers.
VERY often, often enough that it's become annoying to manage, the files received on the data silo in my office via intelligentFTP fail their verification process.
Is iFTP that feeble? Is this to be expected? It is some sort of configuration issue on my end? Anything specific I may check for?
I have noticed an issue where ImageManager sees a bad.log file among the images and then assumes a notification has been sent/submitted. At this point no notification is provided that the bad.log file exists.
ImageManager should harang everyone it can that a bad.log file exists, even if the backup chain has been corrected. The reason for this is in providing a persistent notification incase the bad.log is associated to an existing chain that may be needed.
Copyright© 2017 - StorageCraft Technology Corporation