June 22, 2009 at 11:26 am
The Transaction Log backup maintenace plan is failing sporadically with the error - Operating system error 32(The process cannot access the file because it is being used by another process.) Once every couple of weeks or so. The latest happened on the weekend (Sat. or Sun.)
The maintenance plan writes the backup file to a different server with is used for all backups (Exchange, file servers, etc...) and runs Ultrabac.
The job will fail once on these days, but run successfully for the remainder of the day.
The event logs on the backup server show nothing during these times. The db server event logs just show the failure.
The network guy does not think this is related to the work Ultrabac is doing but we are not sure.
Not sure where else to look for a cause?
Thanks.
Robb
June 22, 2009 at 11:32 am
It could be an intermittent network issue. The best thing to do is actually perform all your backups to a local directory and then move (or copy) the backup file to the network location. Network issues can easily cause a backup to fail.
June 22, 2009 at 12:01 pm
This usually happens around the same time of day when it does happen.
The initial transaction log backup is at 7:15 am and they follow every hour, at the top of the hour.
The failures have been at either 7:15 or 8:00 am so far.
June 22, 2009 at 12:11 pm
What is happening on the network during that time? Any network backups, large data transfers between systems, heavy user activity? Anything that may cause a delay on the network can cause a failure of the backup to a network location. Again, that's why a backup to a local resource is recommended then move the file to a network location.
June 22, 2009 at 12:49 pm
Suggestions on utilities or methods of copying .bak files to other locations?
June 22, 2009 at 1:33 pm
Are you backing up to a differently named file each time? Or, are you backing up to the same file all the time?
If the same file, then you are probably running into an issue with Ultrabac backing up the file when you try to access it for your backup.
If not the same file, check for a process on the SAN that is performing a snapshot/snapclone/etc... for the volume you are trying to backup to.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 22, 2009 at 1:41 pm
Jeff-
Same file for Transaction Log backup.
Init on the first run and append there after.
Robb
June 22, 2009 at 1:50 pm
Robb (6/22/2009)
Jeff-Same file for Transaction Log backup.
Init on the first run and append there after.
Robb
And there is your problem. Find out what time that file is getting backed up to tape and you'll find that it is at the same time you are failing.
Another problem you have is that you are initializing that file. If that file is not backed up to tape, or copied to offline storage, or copied somewhere else before you initialize the file you have just lost your ability to recover to a point in time prior to that initialization.
Just think what is going to happen if an hour after you initialized that file you find that you have a problem that is going to require restoring the database and applying the transaction log backups up to 7am? For example, someone comes to you and says that they accidentally deleted a bunch of data they shouldn't have and it occurred at 7:10am?
How are you going to restore the system?
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
June 22, 2009 at 2:17 pm
True, there is a window of time between the first full backup @ 4a and the first trans log backup @ 7:15a but there are not many users (if any) during that time. We are not a 24 hour shop.
June 22, 2009 at 2:27 pm
Robb (6/22/2009)
True, there is a window of time between the first full backup @ 4a and the first trans log backup @ 7:15a but there are not many users (if any) during that time. We are not a 24 hour shop.
Really doesn't matter if you are a 24 hour shop or not. If you initialize the file, and someone comes to you after that has been done where you need to restore to a point in time prior to that initialization, where are you going to get the file that contains those transaction log backups to restore from?
Remember, once you initialize the file - there is nothing in it. All previous backups are gone and no longer available.
If that file is backed up prior to your initialization (e.g. copied to tape, copied to other location, etc...) then you can get that backed up file and use it. However, if that file has not been copied anywhere that is accessible you have no way to recover to a point in time.
The same thing goes for your daily backups. If you are initializing the file, you need to make sure that file is copied off somewhere before it is initialized.
My guess is that your Ultrabac backups are done around 7am in the morning. This would make sure the current backup has been copied - but are you sure the transaction log backup file has been copied before you run the first job @ 7am that initializes the file?
This is one of the many reason why I do not utilize a backup device in my maintenance plans. I create a new file every time, that way I can be sure that the files stay around until they have been backed up to tape.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
July 1, 2009 at 6:47 am
Jeff-
Sorry for the delay in responding.
I have restructured the maintenance plans to create individual files for each back up and only keep a 24 hour "set" of the files on disk. These files are backed up to tape daily.
We will see if this approach resolves the access issue to backup server.
Thanks.
Robb
July 1, 2009 at 11:53 am
Robb (6/22/2009)
Suggestions on utilities or methods of copying .bak files to other locations?
I've used robocopy in the past to successfully and reliably copy backups over to remote sites.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply