ShadowProtect and SSD compatibility issues? Why would some backups take 1 hour, others take less than a minute
We got a client a new Dell Optiplex - with i7 and 16GB RAM, so not a shabby machine - that came with a 256GB mSATA drive installed. Dell put windows 10 Pro on this drive. We added a 1TB standard platter hard drive for data storage.
We installed shadow protect v 5.2.7 and have it do incremental backups every 4 hours of both drives to an external WD my passport ultra connected to the computer via a USB3 port on the PC using the WD's supplied USB3 cable. Shadowprotect is activated. The images are encrypted using
Then at night, that same computer has imagemanager consolidate the images using their typical settings.
So overall, a routine configuration I would think.
This is the first machine that we are using ShadowProtect on an SSD type of device. Are there any conflicts between SP and mSATA drives?
The problem is that while most times, backups of both drives take a couple or few minutes. about once a day, we are seeing the C drive taking upwards of 1 hour to complete the incremental backup.
I can't attache logs here I don't think. Looking at the logs of a quick vs. slower backup.
a quick backup might run from 18:00:00 to 18:00:41
On longer backups, there's 2 pauses. They appear at 00:20 and 03:23. Here's the entries for an incremental backup starting at 18:00:00:
28 Mar 2017 18:00:20 sbcrypt 109 filter started
28 Mar 2017 18:00:20 sbfile 101 successfully opened file z:\sp\officce1 C_VOL-b001-i069.spi filter started
28 Mar 2017 18:00:20 sbvol 108 Image will not have disk ID and partition info (-1392 invalid data format)
28 Mar 2017 18:03:23 sbcrypt 107 compression mode: 5
28 Mar 2017 18:03:23 sbcrypt 107 encryption mode:4
28 mar 2017 18:03:23 sptcrypt 600 please enter the encryption password
28 mar 2017 18:03:23 sptask 101 answerr was sent as UNICODE string
28 mar 2017 19:03:23 spvol 109 last volume read done
Interesting that there's an exact 1 hour gap at 18:03:23. I guess something timed out after an hour and then it proceeds?
The rest of the entries in the log all are time stamped the same 19:03:23 time stamp:
tail started
fini done
MD5 [dnd't bother tyoing all that].spi
ok z:\sp\office1 C_VOL-b001-i069.spi
fini done
incremental tracker reset ok
fini done
process finished successfully
snapshots were destroyed
Again, this is maybe once a day. some times none on a day. I haven't asked the user if they are using the machine before the longer than usual backup - I would think they were and there was changes that were in the snapshot.
This is for the drive with the OS on it. The user is not doing more than Word, Excel, outlook, web browsing.
Successful backups(I am looking at the log from the 14:00 backup the same day) also have the "image will not have disk ID and partition info" entry at 00:20, but the next entry is at 00:21
And the gap between answer was sent as unicode sting and last volume read done is only 20 seconds, not an hour.
Any thoughts? is that -1392 invalid data format anything to be concerned about? It appears in both fast and slow backups.
We installed shadow protect v 5.2.7 and have it do incremental backups every 4 hours of both drives to an external WD my passport ultra connected to the computer via a USB3 port on the PC using the WD's supplied USB3 cable. Shadowprotect is activated. The images are encrypted using
Then at night, that same computer has imagemanager consolidate the images using their typical settings.
So overall, a routine configuration I would think.
This is the first machine that we are using ShadowProtect on an SSD type of device. Are there any conflicts between SP and mSATA drives?
The problem is that while most times, backups of both drives take a couple or few minutes. about once a day, we are seeing the C drive taking upwards of 1 hour to complete the incremental backup.
I can't attache logs here I don't think. Looking at the logs of a quick vs. slower backup.
a quick backup might run from 18:00:00 to 18:00:41
On longer backups, there's 2 pauses. They appear at 00:20 and 03:23. Here's the entries for an incremental backup starting at 18:00:00:
28 Mar 2017 18:00:20 sbcrypt 109 filter started
28 Mar 2017 18:00:20 sbfile 101 successfully opened file z:\sp\officce1 C_VOL-b001-i069.spi filter started
28 Mar 2017 18:00:20 sbvol 108 Image will not have disk ID and partition info (-1392 invalid data format)
28 Mar 2017 18:03:23 sbcrypt 107 compression mode: 5
28 Mar 2017 18:03:23 sbcrypt 107 encryption mode:4
28 mar 2017 18:03:23 sptcrypt 600 please enter the encryption password
28 mar 2017 18:03:23 sptask 101 answerr was sent as UNICODE string
28 mar 2017 19:03:23 spvol 109 last volume read done
Interesting that there's an exact 1 hour gap at 18:03:23. I guess something timed out after an hour and then it proceeds?
The rest of the entries in the log all are time stamped the same 19:03:23 time stamp:
tail started
fini done
MD5 [dnd't bother tyoing all that].spi
ok z:\sp\office1 C_VOL-b001-i069.spi
fini done
incremental tracker reset ok
fini done
process finished successfully
snapshots were destroyed
Again, this is maybe once a day. some times none on a day. I haven't asked the user if they are using the machine before the longer than usual backup - I would think they were and there was changes that were in the snapshot.
This is for the drive with the OS on it. The user is not doing more than Word, Excel, outlook, web browsing.
Successful backups(I am looking at the log from the 14:00 backup the same day) also have the "image will not have disk ID and partition info" entry at 00:20, but the next entry is at 00:21
And the gap between answer was sent as unicode sting and last volume read done is only 20 seconds, not an hour.
Any thoughts? is that -1392 invalid data format anything to be concerned about? It appears in both fast and slow backups.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Thanks for the reassurance on that message... but any thoughts on why there's a 3 minute delay between that and the compression entry in the log. And then 1 hour to get to last volume read done?
Just looked at yesterday's daily backup report from SP. It's doing 5 backups a day. Yesterday bckups got longer as the day went on (and the machine is in a home office, so saw more user activity. I guess i have to look at other machine's logs that don't have an SSD to see what their numbers look like. it's at 10% performance throttling. Any advice on that? Figure if it's backing up during the day, don't want to suck up too much performance? I guess 100% would help the speed at the expense of performance?!
THe C drive took 24 sec, 59 sec, 39sec, 16 min, 45 min
They Y drive (the data drive) took 2 sec, 30 sec, 15 sec, 3 sec,, 4 sec.
I suppose imaging the C drive isn't as critical as the Y drive - the C is (mostly) OS / program files. The 'important stuff that changes / gets created is the data drive'. I could change C drive schedule to 1x a day? Should I have to? Do you use 10% performance throttling?
Just looked at yesterday's daily backup report from SP. It's doing 5 backups a day. Yesterday bckups got longer as the day went on (and the machine is in a home office, so saw more user activity. I guess i have to look at other machine's logs that don't have an SSD to see what their numbers look like. it's at 10% performance throttling. Any advice on that? Figure if it's backing up during the day, don't want to suck up too much performance? I guess 100% would help the speed at the expense of performance?!
THe C drive took 24 sec, 59 sec, 39sec, 16 min, 45 min
They Y drive (the data drive) took 2 sec, 30 sec, 15 sec, 3 sec,, 4 sec.
I suppose imaging the C drive isn't as critical as the Y drive - the C is (mostly) OS / program files. The 'important stuff that changes / gets created is the data drive'. I could change C drive schedule to 1x a day? Should I have to? Do you use 10% performance throttling?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
But I can't help but make a joke of their info - NOTHING against you :)
so it's either
not an error you should be worried about
or
The file or directory is corrupted and unreadable.
sounds like we narrowed it down : )