twickland

I just installed Retrospect on an M1 iMac and noticed there is no process named Retrospect Engine visible in Activity Monitor, so it must be operating under a different name. Does anyone know what that is?

Thanks, David, for the heads-up. The update release seems to have fixed the problem. After updating, there was one last gasp from the client with the -530 error, and since then, it's been back to normal; no further -519 or -530 errors for proactive backups.

Prior to version 18.1, we would get -519 (network communication failed) or -530 (backup client not found) errors only during regular scripted backups and not with proactive backups. This of course makes sense, since the whole purpose of proactive backups is to catch and back up clients when they appear on the network. Since upgrading to 18.1, Retrospect is consistently reporting a -530 error for one backup client and a -519 error for another. (These are not the same two clients described in my recent post about storage groups.) Because a proactive backup script constantly pings clients to see if they're online, the Operations Log is filling up with hundreds of these spurious and useless error messages. Thank goodness, this is an issue for only two of our 24 backup clients. While not a fatal problem, it sure is annoying. Update: While typing this entry, I just started getting -519 errors for two more clients. I'll need to see if these become consistent, like the other two have been. Has anyone else seen this?

Since the storage group disk media set was failing only with new backups, I decided simply to use it only for restores going forward and to create a new regular disk media set for new backups. As for the media set password, I use the same password for all our media sets. That would indicate either that I mistyped the password when creating the media set or that something became corrupted after the creation.

Numerous people, notably David Hertzberg, have questioned whether using Storage Groups is a good idea. We have been using a Disk Storage Group media set for over a year with no particular issues until last week, when we started getting strange errors for two clients: Can't access Backup Set [Username], error -2262 (Catalog File in use by another machine) Neither quitting and relaunching Retrospect Engine nor rebooting the backup computer made any difference, and when I attempted to rebuild the catalog, I was unable to do so because Retrospect failed to accept the media set's password. (And that even though the media set was configured to remember the password for any access.) This issue cropped up shortly after upgrading to v18.0.0, which may or may not be relevant.

Sometimes the engine gets stuck in some mode where it needs a force quit. It's probably easiest to do this in Activity Monitor.

I'm curious why you have installed the Retrospect server app on the client FS SERVER. I wonder whether this could be part of the problem; say, if the external volumes on that machine have been reserved for a local backup. Should we assume that there's no problem that the local volumes JRP DATA and JRP DATA BU are shown as offline?

We have solved the problem. The cause seems most likely to have been Retrospect's new automatic client update feature. In any case, at some point the client software on the affected machines became corrupted or was actually deleted. In the cases we tested, if the client was removed from the sources list and we attempted to re-add it, the process failed due to an incorrect public/private keypair. We decided to just go ahead and reinstall the client software locally on all our "invisible" Windows clients, which solved the problem; we did not need to delete any client configuration files, so these must have been OK.

Yes, clicking on "Add source directly..." and entering the client's IP address. We need to do this because our IT people block multicast and the clients are found in multiple subnets. Incidentally, for clients added by the direct method, Retrospect typically displays the -519 error message (rather than -530) when the client is simply not visible on the network. It even shows -519 in the add client dropdown if one enters an unassigned IP address. As for the Windows client that briefly went incognito, it's now back and being backed up successfully. We have a total of 20 Windows clients, only four of which are currently able to be backed up. Three of those are on Windows 10 and one is on Windows 7. Knowing the users, I have a suspicion that those three Windows 10 machines may not have had the latest security patches applied. Our networking people say there have been no changes to our wired network (we don't use WiFi for any backups). I haven't yet heard from our desktop support folks to get their take on this issue. Something is definitely amiss, as the client machines that are not visible on the network in Retrospect are also unresponsive when port 497 is pinged.

We have run into a peculiar issue where most of our Windows 10 client machines can no longer be backed up. They are all connected via direct IP (due to our network's security settings), and have a variety of different client versions from 15.6 to 16.5.1. On each machine, the Retrospect Client app appears to be normal, the IP address has not changed, the Windows firewall is set to enable communication, and the computer is awake, but when access is attempted from the backup server, we get a -519 error. Mac client machines are unaffected. Even more oddly, a newly-added Windows 10 client was able to be backed up once before going incognito. I assume this is most likely an issue with our local network, since I would think if the problem were more widespread, there would have been other posts to this forum. Any ideas as to what might be the issue here, so I can intelligently discuss the problem with our network techs, who have no knowledge of any particular requirements that Retrospect might impose? Does Retrospect still use TCP and UDP port 497? We're running Retrospect 16.5.1 server on MacOS 10.14.6. Thanks.

I think this should work:

We recently ran into a number of issues with backing up certain client favorite folders. These all occurred shortly after upgrading to v 16.0.1, which may or may not be a coincidence. In one case, a client favorite folder began showing up the the Sources list with the tilde "offline" icon. Browsing the drive volume showed the folder as still having the stripe icon. To solve the problem, I needed to forget and re-add the favorite folder. In a second case, the favorite folder was not being backed up, returning a -519 network communication failed error. However, I was able to browse the folder in question from the Sources list, after which it was able to be backed up normally. In several other cases, the folders stopped backing up with a proactive script. After backing them up with a regular script, they were once again backing up with the proactive script. I discovered these issues after the clients appeared in the "No backup in 7 days" list. For now, I will assume the problems have been fixed. The issue was reported to Retrospect Support

The peculiar reported capacity of these tapes may be related to the media set locked-unlocked bug I reported here back in 2015 that still has not been fixed.

The actual data in your media sets and the media set catalogs will be unaffected by creating a new configuration file. You will need to point Retrospect to the locations where the media set catalogs are located, but if the catalogs themselves and the data on the disks and tapes are not corrupt, you should be fine here. The hassle will be to manually recreate all your scripts and schedules, any custom rules you may have had, and your source lists, especially if they contain favorite folders. Many of us have begged for years to have Retrospect split the various aspects of its configuration into separate files, or at least to enable users to export and reimport scripts, lists, etc., so that everything doesn't need to be manually re-entered when corruption occurs. Good luck!

As a point of reference, I'm running Retrospect Single Server Version 15.6.1 (105) on MacOS 10.12.6. The top-level dashboard items are visible whether or not the management console is enabled. Lennart, a question for you: Can I assume that when you select "Past Backups," what you see is just the listing of past backups and not the spiffy and colorful pie charts, bar graphs, and other doodads that are supposed to be present on the dashboard when the server itself is selected?