Knowledge Base & Discussion Forum

Extremely frustrating problem

Past technical discussions on Ahsay's Products

Moderator: Support Team

Extremely frustrating problem

Postby Peter Trembath » Mon Apr 08, 2013 5:05 pm

For some time now we have been experiencing the following problem.

On large file uploads, such as mailbox.edb files or system state backup files, the file upload will hang at 99% complete, there will be a message in the client backup log

"[com.ahsay.obc.core.bset.file.H] <Reply><Err>null</Err></Reply>"

then "retry sending the file again in 120 second(s) (E:\WindowsImageBackup\Microsoft_Win2008_Sysstate_Backup)"

Then after some time the file starts to re-upload from 0% again. This cycle continues until the backup is cancelled.

Meanwhile the server log shows the following error:

"Failed to process new file requests for user=ExamplesBackupSet=1360315635640 File=EQDC1\Microsoft_Win2008_Sysstate_Backup"

There are no connectivity problems between client and server.

Both server and client are version 6.13.0.0

Ahsay tried to tell us it is disc corruption at the backend server, but this is not the case.

Does anyone have experience of this? Did you manage to fix it?
Peter Trembath
 
Posts: 26
Joined: Thu Oct 07, 2010 6:06 pm

Postby Peter Trembath » Wed Apr 10, 2013 4:38 pm

Hmmmmm... not a single reply despite numerous posts! Perhaps it is unique to us. I really need to confirm this!

Can I ask, can anybody who reads this just confirm that they have never experienced this problem? Thanks very much.
Peter Trembath
 
Posts: 26
Joined: Thu Oct 07, 2010 6:06 pm

Postby Support3 » Wed Apr 10, 2013 5:43 pm

May I ask what is the ticket ID submitted? We shall further follow-up in the ticket submitted.

Thanks.
User avatar
Support3
 
Posts: 6075
Joined: Wed Jan 02, 2008 11:08 am

Postby Peter Trembath » Fri May 03, 2013 4:55 pm

Hi Charles

The .edb is working correctly and there is plenty of storage space on the backup server. We are a commercial backup provider with a large storage array.

What worries me is that we are seeing this problem with a significant number of different customers' backups, always involving the upload of a very large file, such as a system state backup file or a mailbox.edb file or delta file.

This problem only started with the upgrade of the software to version 6.x.x.x. I cannot tie it down to a particular release.
Peter Trembath
 
Posts: 26
Joined: Thu Oct 07, 2010 6:06 pm

Postby NAUser » Fri May 03, 2013 5:57 pm

This sounds a bit like Ahsay is trying to upload the original file and not a temporary copy. What can happen, when you try to transfer the original of a very large file, is that the file may be amended during the duration of the transfer with the result that the consistency check at the end of the transfer fails - the uploaded file no longer matches the original.

The larger the file, the longer the transfer takes, which allows more time for changes to occur to the file whilst the transfer is running. I would assume that Ahsay made a temporary copy of the file on the client precisely to avoid this but it can be problematic if there's not much space on the client.
NAUser
 
Posts: 15
Joined: Thu Apr 25, 2013 6:31 pm

Postby Peter Trembath » Fri May 03, 2013 6:01 pm

NAUser wrote:This sounds a bit like Ahsay is trying to upload the original file and not a temporary copy. What can happen, when you try to transfer the original of a very large file, is that the file may be amended during the duration of the transfer with the result that the consistency check at the end of the transfer fails - the uploaded file no longer matches the original.

The larger the file, the longer the transfer takes, which allows more time for changes to occur to the file whilst the transfer is running. I would assume that Ahsay made a temporary copy of the file on the client precisely to avoid this but it can be problematic if there's not much space on the client.


Thanks for the input Nauser, but is that not exactly the reason why the Shadow Copy Service takes a snapshot of the files before the backup starts? If there was not enough space on the client drive the Shadow copy would throw up an error would it not?
Peter Trembath
 
Posts: 26
Joined: Thu Oct 07, 2010 6:06 pm

Postby NAUser » Fri May 03, 2013 6:12 pm

Yes - that's certainly what I would expect Ahsay to do, because it is a quite well known 'gotcha'.

I only mentioned it because the symptoms matched that scenario - after completing 99% of a transfer any failures that then occur are usually in the consistency check phase. Could something be occuring on the client that's changing the shadow copy?
NAUser
 
Posts: 15
Joined: Thu Apr 25, 2013 6:31 pm

Postby housey » Thu Oct 31, 2013 1:52 am

Hi Peter

Did you ever get to the bottom of this?

I am seeing exactly the same issue on a couple of customers.

Large exchange database, uploads 100% then I receive

[2013/10/30 16:16:29] [info] Uploading New File ... 100% of "Microsoft Exchange\DAG1\DB2\DB2.edb"
[2013/10/30 16:31:31] [info] [com.ahsay.obc.core.bset.file.H] <Reply><Err>null</Err></Reply>
[2013/10/30 16:31:31] [info] Retry sending the file again in 60 second(s) (\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy550\EXCHANGE\DB2\DB2.edb)

on the OBS side this is logged

SEVERE: [error][system][NewFileRqt.doNewFiles] Failed to process new file requests for user=xxxxxxx sBackupSet=xxxxxxxxx File=Microsoft Exchange\DAG1\DB2\DB2.edb

Im using obm and obs 6.13.4.0 and opened ticket id #ISX-606-39930 with Ahsay.

Paul
housey
 
Posts: 129
Joined: Wed Nov 08, 2006 9:53 pm


Return to Archived - Technical Discussions

Who is online

Users browsing this forum: No registered users and 5 guests

Looking for Rbackup Alternative | Vembu Alternative | Novastor Alternative | Asigra Alternative | BackupAgent Alternative? Try our product.


A wholly owned subsidiary of Ahsay Backup Software Development Company Limited  [HKEx Stock Code: 8290]