The current version of ShadowProtect on the US website is 4.1.5, and on the Australian website is 4.1.0. I’ve recently had a few issues with high CPU utilisation in ShadowProtect and had of course upgraded to the latest version thinking the issue would be resolved. Unfortunately there is an issue under investigation at the moment that some people are experiencing that occurs with both 4.1.0 and 4.1.5. I spoke to the local ShadowProtect Guru –Jack Alsop and sought his thoughts. His comment to me was that the issue, due to flaky network connections, will be addressed shortly in a newer release, but that for now – the best version to run is 4.0.5. Now ShadowProtect 4.0.5 has some very cool features and I think you should seriously consider moving your clients up to that if they are not on it now. Some of the key features in 4.0.5 include;
1. File System Dirty Detection – when the NTFS file system is shutdown in a normal manner, it marks the volume as “clean”. When however the file system shutdown is not normal, ie a BSOD, then it marks the file system as “dirty”. When NTFS is in it’s dirty state, the data on it may not be consistent. Prior to 4.0.5, ShadowProtect would not check this flag and therefore there was the potential that it would continue to backup the system even though the file system was not in a consistent state. It can do this because ShadowProtect backs up at a sector/block level vs a file level which is cool. The downside to it though is that it might well be backing up a volume that is not restorable due to the inconsistency that is there to start with – think garbage in… garbage out. With 4.0.5, StorageCraft introduce a dirty flag check which means that when doing it’s normal incremental backups, it will check the status of the flag. If the flag is marked dirty, then it will fail any scheduled incremental backups on that volume – this way you know about it and can run a CHKDSK to clear up any issue sooner than later. As a workaround, you can still force a full backup or force an incremental backup of a dirty volume but all scheduled backups will fail – which you might want to do in situations where a disk is going bad so you can recover as much as possible.
2. Mounting\Restore of an image chain – StorageCraft have optimised the algorithms they use so that when restoring a system. The result is that in 4.0.5 it would now restore faster than previous versions.
3. The Win PE recovery environment is now based on Windows 7\Windows 2008 R2 with no added drivers. Why is this a good thing you ask? This means that this environment will boot cleaner and quicker with just the base set of drivers that these OS come with and if you look on the CD you will see a directory called “Additional Drivers” with sub directories that contain drivers that have been tested that you can load to use Mass Storage Devices ETC. This directory is never used for boot processes but somewhere where you can store your drivers and allows you to better handle your own situations easily.
4. Email reporting has been completely overhauled to provide a better experience and a much improved reliability over the previous versions.
5. Final issue – where your ShadowProtect install intermittently seems to lock the server and the ShadowProtect logs reports that for the last (server locks) backup, the server took 10 minutes instead of seconds to create the “snapshot” and it used VSNAP instead of the Shadow Protect provider. There exists a patch that will fix this issue and it is to do with the ShadowProtect Volume Storage Manager. Contact StorageCraft APAC support to get this last patch.
As always this information is accurate as of today. StorageCraft have already indicated they have another version on the way soon and pending its release and testing it may well be the better version to go for.
Have been seeing an issue on a client of ours with v3.5.2 on SBS2011 where the incrementals performed during the day are massive (over 1gb in size). The only directory really increasing in size (not in 1gb chunks however) from day to day on this server is the Exchange Mailbox Database directory (usually log files and then the actual db) , but continuous incrementals performed (3 times a day) continue to increase in size with every backup at about 1gb+ every time – even if we bring this down to performing a backup every hour, same thing. We are using continuous incremental with VSS option.
Not sure what might be causing this as the amount and size of files on the server are not really changing in those sizes hour to hour. Not sure if it could be a bug or incompatibility with SBS2011 / Exchange 2010???
Has anyone seen this?
Regards,
Richard
Miami, Fl.
Hi Richard,
First up – I’m not sure that SP v3.5.2 is supported on SBS 2011 – you might want to upgrade to the most current which is 4.1.5.10129 which I’ve found works pretty well. As for the log files, it’s possible dependant on email traffic within the network for the exchange log files to be quite large and therefore cause your incremental backups to be similarly large too.
Wayne