No snapshot stored after error -519 (network communication failed)

[mplehman]

Every time part of a backup routine is incomplete due to a -519 error, it does not store a snapshot. So I've got nearly 400GB of data that is backed up, but isn't in the catalog. If an execution is incomplete for other reasons (e.g. - file deleted during backup so it's missing), a snapshot is stored. I'm assuming the only way to recover this is to Rebuild the media set's catalog. Obviously not what I would prefer.

 

- 2/3/13 1:22:30 PM: Copying production on Kermit

Using Instant Scan

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

2/3/13 5:25:12 PM: Execution incomplete

Remaining: 1343 files, 14.2 GB

Completed: 82014 files, 397.2 GB

Performance: 1,691.9 MB/minute

Duration: 04:02:42 (00:02:17 idle/loading/preparing)

[Lennart_T]

A -519 error means that the client no longer communicates with the Retrospect Server. The most common reasons are:

Client user disconnected the network cable.

Client user connected to another network using VPN.

Client computer shut down.

Client computer went to sleep.

 

Just backup the client again, no need to rebuild the catalog file.

[mplehman]

I understand the meaning of the error. None of the potential reasons given are the case here however. Retrospect seems to be flakey when it comes to systems with multiple network interfaces on different subnets. What I believe is causing the network connection failure is that it's connecting to the client's interface that is not on the same subnet as the backup server's interface. This causes the traffic to go through the router (100Mb connection) rather than just the switch (1000Mb connection), and it's gridlocking the link and causing a communication failure. I've tried adding Sources by direct IP. I've tried removing the undesired network interface from the Retrospect Network preferences and it just keeps coming back as Default whenever the engine is restarted. I've now gone so far as to firewall all Retrospect and mDNS traffic via that interface and the Source settings appear to be holding since then.

 

"Just back it up again" isn't really an acceptable solution. Granted, it's the only solution that will give me a complete backup at the moment, but it is not acceptable as a matter of routine. Also, rebuilding the catalog did no good. All the files appear to be on the tapes—I can see the "missing" files being referenced during the rebuild process and the number of files and size of the backup correspond with them being there, but let me try and explain my concern. When I go to do a restore, I have to select a backup snapshot. Because I've done a followup backup, there is snapshot for the volume in question so I can select the files just fine. Here's the problem though: If the file was deleted or changed between the backup with no snapshot and the one with a snapshot, how do I get the file as it existed during the backup with no snapshot? There's no earlier snapshot to retrieve, so as far as I can tell, I don't. Also, say the drive up and dies before I have a chance to do a followup backup. Now I have no snapshot to select so I have no way of selecting the files for restore.

 

This is backup software. Of all software, it is something you should be able to depend on. If you can't, it's not much good. In my opinion, it should still be storing a snapshot of the files that it completed successfully. If not, I don't think it shouldn't consider them backed up.

 

Having said that, v10 does seem to finally be a viable replacement for v6. I just need to figure out how to make it play nice on the network.

[Lennart_T]

"Just back it up again" isn't really an acceptable solution. Granted, it's the only solution that will give me a complete backup at the moment, but it is not acceptable as a matter of routine.

Of course it isn't. Not as a routine. But now, to urgently get your first backup.

 

When I go to do a restore, I have to select a backup snapshot.

In version 9, you can perform a search for files and restore without a snapshot. It's probably the same in version 10.

 

 

I say you do have a network problem, not a Retrospect problem.

With Retrospect, the connection has to be kept open continuously for several hours.

For instance, with file sharing the connection only needs to be open for the few seconds it takes to copy that file. So the probability for failure is much less than with Retrospect.

 

We had something similar a few years ago. One server had two NICs, one should be acting as a hot spare for the other. Our client/server programs worked for an hour or two and then the connection was lost. It turned out that the two NICs were competing with each other, rather than one acting as a backup for the other. So when the other card took over, the connections were disconnected.

[twickland]

A comment on the snapshot issue:

 

Back in the days of Retrospect 6, I'm almost certain the snapshot was generated before the backup began. While this had the advantage of providing a snapshot even if the backup were subsequently interrupted, it would also mean that if you tried to restore from that snapshot, some of the files would not be available, since they were not backed up.

 

I think the current arrangement—where the snapshot is generated and added to the catalog after the backup has completed but before the compare phase—is probably better, as it ensures that all the files in the snapshot were actually backed up and are available for restoring.

 

As Lennart notes, you can always restore files by searching for them, whether or not you have a snapshot for a particular backup session.