macpro

I'm seeing the same behaviour under the same circumstances. Backing up to external hard drives.

Today on my MacBook the Retrospect Client icon appeared with an exclamation mark. The control panel informed my that the client was waiting for the Retrospect login. Why? I don't know. The client had been installed ages ago and I haven't made any changes to it. It only had the client software upgraded to 18.2 via the automatic client update but that was a couple of days ago. But now I'm facing that wonderful error -525 on the server. Retrospect says my MacBook is not the MacBook it used to be. So all I have to do is forget the client and add it back. Easy, except for one thing: I have 20 favorites on this Mac. And they have each their own script to save data. Which means I have to add 20 favorites back and then modify 20 scripts again to get my backups up and running again. But what am I complaining? It only takes 1 hour to get it al how it was before the Retrospect client decided to do it's thing. This behaviour should be fixed. Error -525 has given Retrospect users lots of unneeded issues. And the whole point of using Retrospect is to be protected against loss of data. But having to lose (read: wipe) configuration data to get backups running again is a joke.

The main reason for me to stop using Storage Groups is that it takes too long to start the Retrospect console. When syncing with the server, it counts up to 149 media sets and when it's done, it actually shows 35 media sets. That's probably because Storage Groups contain "sub media sets".

Because I got no response yet, I decided to try one set of hard drives last weekend. You can use FileVault on external drives. Just select the drive on the Desktop and use "Encrypt <volume>" (Not sure about the name, I'm using a Dutch version of macOS.) The Mac will ask to provide a FileVault password to decrypt the data and then asks to reboot so the encryption process can start. The only drawback I anticipated was that I would have to enter the password everytime I mount the disk. But I don't have to, because it's possible to store that password in the keychain. Just as you mentioned above. The nett result after a week of testing? Works without any troubles. I haven't had any issues with Retrospect so far.

All my disk media sets are stored on external disks. They are not encrypted at the moment, but I would like to enable that. If I want to use encryption from Retrospect, I have to recreate the disk media sets. Thus losing a lot of backup history. But I could also use FileVault to encrypt the external disks. Then I do not need to recreate the disk media sets. The only drawback I can think of at this moment is that I'll have to enter the encryption password everytime I mount the backup disks. Has anyone tried this approach already? Any thoughts on why this could be good or bad?

Thanks for that link. It helps in trying to estimate what cloud backup could cost. @andymac: Ever since Retrospect is on it's own feet again they have been delivering a big update every year. I've updated a couple of times and also skipped versions, but in the end I always had to pay a rather large amount for an update. This year I've bought my last update and added ASM. So next year I'll pay less and still remain up to date. The reason that I've switched to ASM is because of the frequent updates that Retrospect has been delivering. It looks like they will continu to do this in the future and that provides an update option at a better price.

They fail because of the missing members. Here's an example: + Normal backup using Backup MBPPRO at 09-08-16 00:00:01 (Activity Thread 1) Can't access Backup Set Backup MBPPRO 2, error -1.101 (file/directory not found) 09-08-16 00:00:16: Execution incomplete

Weird: I rebuilt two media sets before I started this topic. Both succeeded, but this time one of the two media sets is again missing the members. + Executing Rebuild at 22-08-16 16:44:10 (Activity Thread 3) To Backup Set Backup MServe 1... Scanned /Volumes/Backups 1/Backup/Backup MServe 1/Retrospect/Backup MServe 1/1-Backup MServe 1/ up to backup set data file index 1.107 Using fast rebuild 22-08-16 16:44:32: Finished scanning backup set data files 22-08-16 17:26:58: Execution completed successfully Completed: 903.278 files, 638,6 GB Performance: 22.850 MB/minute Duration: 00:42:42 (00:14:05 idle/loading/preparing)

Just curious: why do you suggest this?

The catalog files are stored on the startup disk: /Library/Application Support/Retrospect/Catalogs The media sets are stored on 6 different disks. And all these disks have this behavior. Disk Utility doesn't show any errors.

I'm running Retrospect 13.0.1 on Mac OS X 10.11.5. Backups are made on external disk with Disk Media sets. On irregular intervals, but lately a couple of times per week, Retrospect shows the media sets as having no members. Which is not true, because the members are just sitting on the disk, ready to be used. I can fix this by rebuilding the catalog and adding the members back to the media set. But a couple of days later, this starts all over again. I've checked the backup logs, but they provide no info that points to forgetting about the members. Does anyone have a clue what might be going on here?

What a coincidence. I was just looking into storing Disk Media sets in DropBox when Retrospect announced version 13 with Cloud backup. The good thing is that I'm sure I'll be able to somehow store an backup offsite. But I'm not sure which way to go. My Disk Media Set is aprox. 600 GB in size and slowly growing. (By the way: is Retrospect capable of forecasting how much PUT/GET/LIST/DELETE actions will be needed, based upon previous backups made?) If I go for DropBox, I can get 1 TB of storage for € 99 per year. And that's it. No fees for uploading or downloading. If I go for one of the Cloud providers, I'll have to pay somewhere between € 25 and € 50 per month according to the calculators. Although I have absolutely no clue about the number of PUT/GET actions I need. Compared to DropBox, that's a big difference in price. Advantages for the Cloud providers are the seeding and large scale recovery options. Uploading 600 GB to DropBox will take a while, but downloading could be relatively fast using a 100 mbits download. If I asume that it will take at least until the next day before my hard drive with the backup would arrive, I can download those 600 GB also in the same time. Security wise I think DropBox will be as secure as the Cloud providers, because I can let Retrospect encrypt the Media Set contents. Any thoughts in this? I'm curious about what others think and If I'm making wrong assumptions.

Last week I received this nice error message. It had been mentioned for a couple of days in the Retrospect mails but I was a bit late in noticing it. So I stopped Retrospect and started it again. What a mistake. Retrospect wouldn't startup at all. I do make copies (besides backups!) from the Retrospect folder in /Library/Application Support, so I copied that back. No luck, because the daily copy had been copying corrupt data for a couple of days. Luckily I was able to restore the folder from Time Machine to the state it was just before I received the message. Retrospect started. But I had lost all logging from the past few days. And I lost members in 4 disk media sets. Which I could only add back by rebuilding the catalog file. Fast forward a couple of days and again I have this message. This time I have used Retrospect to restore a know good backup in advance before I shut it down. And I've searched this forum to see other experiences. Seems that I only have to restore the config file, which in my case would mean Config80.dat. That's right. I'm running Retrospect 11.5.3. And that config file is 2,38GB in size. Ran Disk Utility to verify the disk and it saw no problems. Restarted Retrospect and as expected: down. Activity Monitor shows a Retrospect process owned by root for a couple of seconds and then it dissapears. Put the config80.dat file backup that I restored earlier in place of the corrupt config80.dat file. Started Retrospect and it's up and running again. So I'm happy? Not at all. Because again I have lost all logging from the past backups. Why? Because Retrospect believes it is a good practice to save log info into the config file. That is why it's 2,38GB in my setup. That is why it gets corrupt because it changes when it shouldn't have to. So thank you very much Retrospect for keeping this "feature" alive and kicking. You have been aware of this for a long time but still see no need to solve it.

Thanks, that's a nice tip. I'll give that a try, although I'm positive it will not make me happy. It's all about occasionally connecting a drive to my Mac and thats most of the time a drive that wasn't connected before. So I would have to do that every time. I'd rather have Retrospect not touch my external drives unless I explicitly use them in backup jobs on the server.

Thanks for the work around, but that's not really a solution for this problem.