Jump to content

RedHat client and error -519


amcmis

Recommended Posts

I have an issue with backing up a Redhat 7.2 system, but it just started recently. It corresponds with a firewall upgrade, but it's still strange. Here's what's up...

 

Server is Retro 6.5 Server, all patched. Latest Linux client. It all worked fine when the server lived on the LAN side of a Sonicwall Pro 300, and the linux box was on the DMZ. We recently upgraded to a Sonicwall Pro 3060, same topology. Now when we back up, it regularly fails with:

 

Trouble reading files, error -519 (network communication failed)

 

...and it always fails at the same place, 234 MB into the backup or so. NOW, HERE IS THE TWIST! I set up a manual backup from the same source to a disk based snapshot, and it sailed thru just fine.

 

OK, here is two long snips from the log, with debugging turned up to 5. The first is the failing one, where we are backing up to tape. The second is from the successful backup to disk.

 

Before you suggest it, I have already played around with port 497 timeout values on the Sonicwall.

 

SNIP1 - Failing

necoCmd: transaction 145: 'VAcc' on "pcpds"

necoDispatch: transaction 145: result 0

necoCmd: transaction 146: 'VAcc' on "pcpds"

necoDispatch: transaction 146: result 0

necoCmd: transaction 147: 'ScTg' on "pcpds"

necoDispatch: transaction 147: result 0

ifacOptValue: 'WODy' undefined, using default value 2

soctSetThread: socket thread now 0x2284

soccOpen: socket send buffer size is 65,536

soccOpen: socket recv buffer size is 65,536

soccCallback: connected

necoOpen: connection established with "mekala.outdoors.org"

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 1: '_gl_' on "RfsDownload"

necoTranGone: transaction 1 disappeared

necoDispatch: transaction 1: result 0 ignored

necoDispatch: transaction 1: result 0 ignored

necoCmd: transaction 2: 'VFnd' on "retropds"

necoDispatch: transaction 2: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 3: 'VGet' on "retropds"

necoDispatch: transaction 3: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 4: 'DInf' on "retropds"

necoDispatch: transaction 4: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 5: 'VGet' on "retropds"

necoDispatch: transaction 5: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 6: 'DInf' on "retropds"

necoDispatch: transaction 6: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 7: 'VGet' on "retropds"

necoDispatch: transaction 7: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 8: 'DInf' on "retropds"

necoDispatch: transaction 8: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 9: 'VGet' on "retropds"

necoDispatch: transaction 9: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 10: 'DInf' on "retropds"

necoDispatch: transaction 10: result 0

necoSetRelease: unreserved

necoSetReserve: reserved for "Preparing..."

necoCmd: transaction 11: 'ScrT' on "retropds"

necoDispatch: transaction 11: result 0

necoSetRelease: unreserved

 

- 2/16/2005 4:49:47 AM: Copying amcweb2 on mekala.outdoors.org

soccRecv: connection closed cleanly

soctPreDispose: maximum queue depth was 1

2/16/2005 4:49:47 AM: Connected to mekala.outdoors.org

necoSetReserve: reserved for "Setting Clock..."

necoSetRelease: unreserved

necoSetReserve: reserved for "Loki-Daily"

necoCmd: transaction 12: 'VGet' on "retropds"

necoDispatch: transaction 12: result 0

necoCmd: transaction 13: 'DInf' on "retropds"

necoDispatch: transaction 13: result 0

necoCmd: transaction 14: 'DInf' on "retropds"

necoDispatch: transaction 14: result 0

necoCmd: transaction 15: 'Scan' on "retropds"

necoDispatch: transaction 15: result 0

necoCmd: transaction 16: 'VGet' on "retropds"

necoDispatch: transaction 16: result 0

necoCmd: transaction 17: 'DInf' on "retropds"

necoDispatch: transaction 17: result 0

necoCmd: transaction 18: 'VGet' on "retropds"

necoDispatch: transaction 18: result 0

necoCmd: transaction 19: 'DInf' on "retropds"

necoDispatch: transaction 19: result 0

necoCmd: transaction 20: 'FFet' on "retropds"

soccCallback: FD_CLOSE responded, error 10053

necoStopAllTrans: stopping 20

Trouble reading files, error -519 (network communication failed)

2/16/2005 4:56:27 AM: Execution incomplete

Remaining: 34067 files, 1.1 GB

Completed: 14003 files, 234.8 MB

Performance: 39.8 MB/minute

Duration: 00:06:40 (00:00:47 idle/loading/preparing)

 

 

 

===============================================

SNIP2 - Succeeding

+ Executing Immediate Backup at 2/14/2005 12:32 PM (Execution unit 1)

MemPack: total heaps = 19

To Backup Set MekalaSnap...

 

- 2/14/2005 12:32:44 PM: Copying amcweb2 on mekala.outdoors.org

2/14/2005 12:32:44 PM: Connected to mekala.outdoors.org

soctSetThread: socket thread now 0x2020

necoSetReserve: reserved for "Immediate Backup"

necoCmd: transaction 11: 'VGet' on "retropds"

necoDispatch: transaction 11: result 0

necoCmd: transaction 12: 'DInf' on "retropds"

necoDispatch: transaction 12: result 0

necoCmd: transaction 13: 'VGet' on "retropds"

necoDispatch: transaction 13: result 0

necoCmd: transaction 14: 'DInf' on "retropds"

necoDispatch: transaction 14: result 0

necoCmd: transaction 15: 'FFet' on "retropds"

necoDispatch: transaction 15: result 0

necoCmd: transaction 16: 'FFet' on "retropds"

necoDispatch: transaction 16: result 0

2/14/2005 12:44:33 PM: Snapshot stored, 9,324 KB

2/14/2005 12:44:39 PM: Execution completed successfully

Completed: 48070 files, 1.3 GB

Performance: 114.1 MB/minute

Duration: 00:11:51 (00:00:03 idle/loading/preparing)

 

soccRecv: connection closed cleanly

soctPreDispose: maximum queue depth was 1

 

============================ End SNIPS

 

Any ideas?

TIA!

jth

Link to comment
Share on other sites

Hi

 

Are there any policies on the firewall that would change based on the time of day?

 

Since you are backing up using the client, manual vs. scripted should not make any difference. Can you run a test script 5 minutes from the current time and see if that fails?

 

Thanks

Nate

Link to comment
Share on other sites

Hi Nate, thanks for the response.

 

There are no time based policies at all, unless there are defaults I'm not aware of.

 

I was planning on doing some more elimination tests. Here are the differences between the two situations i've already submitted:

 

- Test 1 is a nightly scripted backup that handles about a dozen different servers to a single sDLT tape. Some servers are RetroClient, others are mapped as volumes, and it also backs up the local drives on the server. Server is Retro Multi 6.5, latest patches and drivers. The snip I provided is from late in the log, I obviously didn't include all of it.

 

- Test2 was a manual backup of just the linux client to a file based backup set.

 

So, various things to look at include:

- scripted vs manual

- time of day

- to tape or to file

- lone server backup or one of many

 

Again, I DO believe the Sonicwall is involved, and I find interesting that it consistently fails at approximately 234 MB, or approximately 5-10 minutes of activity. I played with conn timeout values on the sonicwall to no avail, but I'm sort of glad about that, because if the Sonicwall was performing an idle timeout on a connection that's pumping data, that would just be wrong.

 

For more info, The SW Pro 3060 is running SonicOS Enhanced 2.5.

 

I will check back in when I've tried a few of the possible permutations. In the meantime, if anyone has any insight, please share!

 

jth

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...