Seeking Retrospect 10.5 - Mac OS Mavericks Advice

[Mark_G]

Very long-time Retrospect user here. Since v6. Last version used was v9.

 

I was extremely comfortable using v6, both in terms of proficiency and trust.

 

But was pushed into v8, then v9, probably because of OS compatibility (can't remember now). 

 

I found v9 to be somewhat lacking. All kinds of weird (even buggy) UI elements really lowered my trust in this product. And this very forum was rife with complaints about versions since v6. But I continued to use it as no competing solutions (at a reasonable price) emerged that were suitable for my need. Despite the UI issues, backups and restores have so far shown to be reliable (but I'm still not "100%" as I was with v6). That was all running on Mac OS 6.8 (Snow Leopard).

 

I've now migrated all my computers (five in total) to Mac OS 9.1 (Mavericks).

 

So here are my questions, to any that would care to weigh in:

 

For those of you with an understanding of the UI issues of v9, would you say I can expect an improved experience with v10.5? Have they fixed everything? Some things? Nothing?

 

Can I now, at least, control the order in which the clients backup? Does the log actually work (while the backup is in progress)? Do the controls available to the clients (via System Preferences and the menu extra) actually work now (never could get that stuff to work)? Etc...

 

Will v10.5 running on Mavericks utilize my v9 backups, or will I be starting from scratch?

 

Would you say the v10.5 is completely compatible with Mavericks? Any known issues?

 

In other words: if you had done a complete clean install of OS (to Mavericks), and restored all data files from cloned HDs, on five local Mac computers, would you upgrade to v10.5 and continue to use Retrospect, and trust it completely?*

 

*By "completely" I mean: I'm not crazy: I also use CrashPlan plus Time Machine plus Dropbox plus clones plus all mission critical drives are raid-mirrored, so Retrospect is only a part of my backup strategy, but I still expect, and want to know, that each component of that strategy is as near-100% reliable as is reasonable to expect.

 

Any/all comments appreciated!

 

 

 

[Don Lee]

comments:

 

1. Be careful when referring to "Mac OS 9.1". I hear the Classic 9.1 in this. You mean Mac OS X 10.9.1 (Mavericks). Not the same. ;->

 

2. Retro 10.5 is a good product. It still has bugs, but the vast majority are fixed, and the performance problems of the early v8 and v9 days are largely addressed. I can't speak for anyone but myself, but I value one feature over many of the others, and that is the ability to "distill" my backups, by combining them as they get older. For instance, you can do a "full" backup every 1st of the month, and then incrementals all month. You end up with separate sets for each month. With retro 9, you could not really combine these sets into a "2013" set, without

loads of duplicate data and/or losing your "snapshots". This works in retro 10.5, and allows me to keep a "2013" set, with all the

*selected* snapshots on tape for long term storage. It's sweet.

 

3. I think upgrading from retro 9 to 10 is a no-brainer.

 

4. I have no Mavericks machines.

[Mark_G]

Thanks iCompute for your response. One vote for "OK to go from 9 to 10!"

 

Anyone else have thoughts and/or answers to the other specific questions I asked?

 

1. Anyone with specific Mavericks (OS X 9.1) compatibility experience? Good or bad?

 

2. Will Retro 10.5 make use of Retro 9 backups, or will I be starting from scratch?

 

3. Can one now control the order in which clients are backed up in 10.5?

[wdroome]

#1: I've used retro 10.5 on MacOSX 10.9.1 for a month now. It seems to work well and it's stable -- although I have a very simple setup.

 

Only two problems: RetroISA wants to scan any disk I connect, including flash drives. What's worse, RetroISA won't let go -- I can't unmount the drive until I stop RetroISA. So I just turned ISA off. Incidentally, with retro 10, you can disable RetroISA from the System Control Panel, rather than with a terminal command.

 

The other problem is that I cannot always update rules. That seems to be a user permissions problem -- to change rules, I have to reboot and login as the admin user that installed retro. Logging in as another admin user doesn't work.

[Mark_G]

Thanks, Wendy, for weighing in. That's good news. I'll heed the info about RetroISA (though I don't yet even know what that is). The permissions issue is "non" for me, as, right or wrong, I'm always logged in as admin.

 

I have to say, I am surprised at the number of responses I've received. I would have thought this to be a bigger, more active topic: v10 and Mavericks. I didn't see any other threads about it. Am I wrong? Or it this forum just not that active?

 

Oh, well, I guess I'll have to roll the dice eventually. I must rely on Retrospect, as I've yet to find a better solution, and I'm now on Mavericks and am not going back...

 

Hmmm, come to think of it, I guess I knew all that before I posted!! 

 

Thing is: I'm still stinging from my experience with Adobe CC. Adobe's website touted completely Mavericks compatibility. And I couldn't Google any problems. It was only after I upgraded to CC and Mavericks, and the nasty problems ensued, that I was able to conjure up Google results (because now I was searching for specific problems.) Turns out there were big problems with CC and Mavericks, acknowledged by Adobe in the forums, but not on their compatibility web page. I find this practice reprehensible, even actionable.

 

[End rant.]

 

I'm just trying to be more thorough this time with Retrospect...

 

Thanks again for your help.

[Maser]

So, I've been running 10.5 with Mavericks without any serious problems.  I have not attempted a "full disk recovery" as I only really back up "/Users" on the machines I back up.   

 

As far as RetroISA scanning external drives goes -- yes, that's a PITA, but if they are the same external drives, you can modify a file so that RetroISA will skip those volumes only.

[Mark_G]

Thanks, Maser. I'll implement Retro 10.5 on Mavericks this weekend and post results. Guess I'll have to study up on RetroISA to see what that is, and if I need it. I don't recall needing it in the past (if it existed before v10). I back up 5 computers to a rotating set of external hard drives, swapping on- and off-site sets periodically. One of the five computers runs the Retrospect server, to which I connect the external drives. Four with the same OS (Mavericks), one an old Leopard Machine I maintain for legacy apps and docs. No WAN stuff, no tape, no Windows. Pretty simple (I hope)...

[prl]

... Guess I'll have to study up on RetroISA to see what that is, and if I need it. I don't recall needing it in the past (if it existed before v10). ...

RetroISA is short for something like Retrospect Instant Scan Agent (not sure about the 'A'). It's the process that listens for file system updates and generates a list of files to be backed up so that the "scan" part of backups can be "instant", since it already has a list of files to back up. The Retrospect documentation is pretty light on how it works. The Instant Scan data is never used for manual backups, so if, like me, you only do backups manually, there's no point enabling Instant Scan.

[Mark_G]

Ah, thanks for the clarification. As I do not use scheduling, but instead initiate backups by selecting the desired script, I assume that means I do manual back ups. So that also means my backups will be as slow as ever (in terms of Retrospect figuring out what needs to be backed up)? Bummer. Though it might be just as well, as:

 

1) RetroISA seems to be a bit problematic, and

2) Is that method of determining files to back up all the reliable?

 

CrashPlan uses a similar scheme, but regularly runs a routine to verify that all files are actually backed up. I believe Time Machine does the same thing: using an OS-maintained "quick list" for the most part, but periodically checking that all files are actually backed up.

 

This seems to me to be a big red flag that the "keep track of which files change" method for quick backups, whether CrashPlan's, Retrospect's, and even Apple's, doesn't work 100%. Computer law dictates the file that inadvertently gets missed in a backup is the one you'll need to restore!!

 

Thanks again for the feedback and tips.

[prl]

Hi, Mark. What you describe that you do is what I meant by manual backups. If you do all your backups like this, you may as well turn off Instant Scan.

 

IIRC, Instant Scan only processses file system changes about once every 5 minutes. I have no idea why that choice was made. That meant that people who'd just made a file modification and then ran a manual backup wouldn't have the recently changed file backed up. So Instant Scan is only used for scheduled backups. See David W Lee's explanation of the process here.

 

IMO, this is the wrong fix, but I'm not sure what the rationale was for the delay on processing Instant Scan files. It seems to me that someone who knows what the backup schedule is and does the file change just before they "know" when the backup will be done will be in the same situation of thinking the backup will be back up their recently changed file, but the backup won't actually happen.

 

I was quite disappointed that I'm unable to use Instant Scan for my manual backups. They could at least have documented the delay in the Instant Scan process, and allowed users to make their own decision about whether to use Instant Scan for manual backups.

[Mark_G]

Interesting, and I can't fathom the logic either. Unless it is because Retrospect's mechanism is resource intensive and every five minutes is their solution to the performance hit. Sounds like lazy programming to me. The last five minutes of any given day is not work I would care to gamble with. And if this omission is not clearly documented?!? Or at all. Kinda inexcusable. This is the kind of stuff that worries me about Retrospect.

 

And I'm no expert on the OS's file-change tracking mechanism, but it seems to me that Mac OS does indeed do this tracking, at the system level. So why not just tap into that database, at the beginning of each backup, scheduled or manual? Why have RetroISA at all? Who knows.

 

I'll just ignore it. Never having used it, I won't miss it! Maybe they'll fix it.

 

What I do miss, however, is the Retrospect Event Handler. Ever use that? It could fire AppleScripts based on the progress of a backup. I used it to shut down systems when backup was complete (among other things). I never cared too much about how long backups would take, I just let them go and the Retrospect Event Handler would close up shop when everything was done. Worked pretty good. But they axed it some time ago. Again, too lazy to keep it active. Or maybe I was the only one that ever used it!! It was kinda obscure, I'll admit. Bummer.

 

I did devise a work-around for the missing Handler, but it is kludgy and untested in 10.5. Hope it still works. It's basically an AppleScript that polls Retrospect's inner files every few minutes until it "figures out" that Retrospect is finished. Something like that. Then it fires its "nighty-night" routines.

[Don Lee]

Just to close the loop.... Retro 10.5 will read your retro 9 (and 8) media sets just fine.

 

FWIW, I run with ISA turned off on both clients and server. It's an attempt to avoid the "scan" time for backups, which annoy users who don't understand why the scans are necessary. For me, the downside of ISA is not worth the upside, and retro works fine without it.