Comments
Sort by recent activity
Ah. Indeed a failure.
Processed 2860 pages for database ***, file ***_Log' on file 1.
BACKUP LOG successfully processed 2860 pages in 0.394 seconds (59.447 MB/sec).
22/08/2006 12:26:02: Warning 141: COPYTO error: Unable to copy U:\LogShippingBackup\LOG_MSSQL_***_20060822_122503.sqb to \\***\LogShippingLanding\LOG_MSSQL_***_20060822_122503.sqb.
*** edited [image]
The servers are seperated by a vpn. What is also of concern is that the vpn went over this morning for a few minutes, resulting in no copy of a log file. The rest then went on their merry way when service resumed.
Is there an option to retry the copy every 10 minutes or so if it fails?
Also this copy failure (and this mornings) did not show in the failure section of the GUI, only in the logs.
Would it be a fair assumption to say that the corrupt files I am experiencing are likely to be a glitch in the vpn - ie the disk space for the file is reserved, partly populated and then the connection goes awol for a moment resulting in a half empty file? / comments
Ah. Indeed a failure.
Processed 2860 pages for database ***, file ***_Log' on file 1.
BACKUP LOG successfully processed 2860 pages in 0.394 seconds (59.447 MB/sec).
22/08/2006 12:26:02: Warning 14...
Ok I had a look with a hex editor, the Orig (corrupt) is filled with 0 from just over halfway through, the Second one(good) has data throughout.
The content prior to that looks the same. / comments
Ok I had a look with a hex editor, the Orig (corrupt) is filled with 0 from just over halfway through, the Second one(good) has data throughout.
The content prior to that looks the same.
Daft question but what do I look at it with..?
:oops: / comments
Daft question but what do I look at it with..?
:oops:
Ah sorry, no. The 'Orig' is the original copied file that failed and broke the logshipping. 'New' is the replacement copied file which was used to restart the logship. Apologies for the confusion with the poor semantics!
Both are supposed to be copies of the same file on the source server. / comments
Ah sorry, no. The 'Orig' is the original copied file that failed and broke the logshipping. 'New' is the replacement copied file which was used to restart the logship. Apologies for the confusio...
hi,
I have found a pair.
New works, Orig does not. By work I mean restore, or convert to sql server file.
MD5s:
Orig: 0FAF7B6268A7626ED5FC59C9B995D7AE
New: F0C3F24AEFF4B40F91D1A8AF4D2B6CCA
File size is reported the same. / comments
hi,
I have found a pair.
New works, Orig does not. By work I mean restore, or convert to sql server file.
MD5s:
Orig: 0FAF7B6268A7626ED5FC59C9B995D7AE
New: F0C3F24AEFF4B40F91D1A8AF4D2B6CCA
File si...
Good question, I shall have a look.
What I do remember is that they have a different modified date on them. The first copied set are 2 minutes ahead of the original files.
Other than that I shall have to double check. / comments
Good question, I shall have a look.
What I do remember is that they have a different modified date on them. The first copied set are 2 minutes ahead of the original files.
Other than that I shall ...
Hi.
No there were no logged network interruptions at all. That was my first thought. We have pretty tight logging of that kind of thing. / comments
Hi.
No there were no logged network interruptions at all. That was my first thought. We have pretty tight logging of that kind of thing.
This sounds like an issue I have recently had.
Was there any useful resolution? / comments
This sounds like an issue I have recently had.
Was there any useful resolution?