Skip to main content

Locking partition C:...

Thread needs solution

Hello

Running Acronis True Image Echo server (build 8,353) on Windows SBS 2003 Server SP2 with nightly backups running but hanging with the last entry in the log with a " Locking partition C:..." message.

Are there are solutions for this issue?

0 Users found this helpful

Hello Court1n,

Thank you for your post. I will definitely help you with this.

Most likely, this issue is caused by our SnapApi drivers not working properly. They are responsible for disk operations and snapshot creation.

To resolve this problem, I would recommend to install the latest build of our software which has the latest SnapApi drivers.

Can you please let me know if a database is included in the backup and if you have VSS enabled?

If you have any other questions, please let me know.

Thank you.

For just over 3 years I've been running Trueimage Echo Server (Build 8,076) on 2 fully patched Windows Server 2003 R2 file servers (running DFS). No problems whatsoever.

The backup was scheduled to run at 9pm, as you can see from the log for friday last (2009-06-19-034310.log) it finished including a full verify at about 3:45am saturday morning, this has been the routine for 3 years. The backup of the duplicate file server is slightly quicker as this has about 50GB of data less. The backup target is a 2TB RAID5 Buffalo Technology Terastation Pro II. The target is made through a mapped drive to a share on the NAS.

At the weekend the server was patched with this months Microsoft Releases and the mapped drive was re-directed to a different NAS a 4TB version of the 2TB Units. It acts only as a target for the two file servers.

On Monday night for some reason after locking Drive D: (a 558GB drive on RAID5 partition) and presumerably backing up that drive, the Scheduled Task 'paused' it was only when I accessed the server that the verify started (about 6:05 Tuesday Morning). I amended Tuesdays scheduled task so that no verify would run and again immediately I accessed the server it completed (see 2010-06-23-061428.log)

My Problem is that at 3am a scheduled task executes elsewhere on the network to copy the *.tibs to external drives for offsite storage.

I have upgraded both servers to Build 8,398 and will report back tomorrow, but could this be the same problem?

Peter

Hello Peter!

Welcome to our Forum, we're glad you joined us!

There could be several reasons for this issue, but yes, you are right, most likely this was the glitch in the low level drivers accessing the drive (SnapAPI). Since you have installed the latest build, SnapAPI drivers got updated, so it is most likely that you will not face this problem again.

Still we would appreciate if you could keep us posted and let us know whether this issue got resolved.

Should you need anything else or have any further questions - feel free to contact us at your earliest convenience, we will be happy to help you!

Thank you!

That has certainly improved things but backing up 190GB across a wire to a switch from the switch to the NAS (both are on the same switch server/switch/nas are in the same rack all run at 1000mbps) still took 6.5 hours (8pm to 2:30am) with no verify.Still too long to include the verify, and with the second server backup directed elsewhere. The NAS Manufacturer has confirmed that the NAS is capable of accepting both data backups (approx 400GB) at 1000mbps in a 3 hour period. The NAS is reporting no errors.

Today I intend to change the port on the switch that the NAS is connected to, this should rule out the switch as a cause as the server operations are normal.

We'll see how that goes.

Peter

Hello Peter,

Thank you for getting back to us.

If I may suggest something, this will help us localize this issue.

Have you tried moving the same amount of data through Windows and see how much time it takes? This way, we can compare the time difference in our software and using native Windows tools.

Please let me know if you have additional questions.

Thank you.