Happy New Year, everyone. I hope that y'all enjoyed yourselves over the holidays and that 2009 is already looking good from your perspectives.
Here at Retrospect HQ, we're running flat out to get a good preview/beta ready for Macworld. There's a lot that isn't finished or hooked up, but you'll soon be able to download a build of the new Retrospect for Mac and at least run a backup (or several at the same time) and get a feel for where we're going with it.
I wanted to take a few minutes to respond to some of the great questions and comments you all have asked here. It's unfortunate that the team doesn't have time available to respond to each comment, but we do read and talk about them. Here are a few of those questions with our overdue responses...
From Russ:
The hardest thing for newbies to grok seems to be the overall Retrospect paradigm, especially those coming from other backup programs. Those who are accustomed to the baseline (or "full") backup, followed by daily incrementals, have a hard time understanding Retrospect's restore model that uses snapshots, and keep trying to fit Retrospect's paradigm into a "restore full, then restore all successive incrementals in order" model.
You're quite right here, Russ. 90% of the file-based (as opposed to image-based) backup software out there, and especially in the Windows world, must be told what type of a backup to perform, such as a full, incremental, or differential. These types of backups choose files based on archive bits, which is a braindead of choosing files. There's no such thing as a type of backup in Retrospect...or in Time Machine for that matter, which helps us somewhat.
Retrospect always performs Smart Incremental backups (yep, that's a new term, though more of a marketing one). Point Retrospect at a destination, and it automatically copies just the unique files needed to complete that destination. Give Retrospect an empty destination, and it will add one copy of every unique file it finds. Give Retrospect a destination with some files already present, and Retrospect will only add a copy of each unique file that isn't already there.
I don't think we've ever done a good job explaining this up front in the documentation, but we will be doing that this time around, and we'll be discussing briefly what some key terminology means up front. And tool tips in the user interface will help, too (though they won't be in the first preview/beta).
From Rick (and several others with similar comments):
I sure hope PPC support is in the initial release, otherwise it's a wait (and not too long or else look for other solutions) situation for me. I don't know whether I'm like other small installations, but while I have several intel based macs on my network, I use an older PPC machine as my central server, which is where Retrospect will need to run.
I estimate that very close to 50% of existing Retrospect installations are on PowerPC-based Macs. After all, Retrospect 6.1 is not Intel-native, and many small businesses tend to give newer Macs to their users, not to the backup/restore task.
While support for PowerPC-based Macs will not make it into next week's beta preview, it will definitely be in the shipping version. The engine (called the Retrospect server) will run under 10.4 and 10.5; the UI (called the Retrospect console) will be 10.5 only, because we're making use of some key interface elements that appeared in 10.5.
From Ronald:
...one of the most important features of Retrospect for me is the ftp backup. Yet it's treated like a stepchild. I hope this gets properly updated in Retrospect X, incl. removal of certain long-standing limitations.
It's funny with all the online/cloud backup services taking off these days, it's easy to see how far ahead of its time Retrospect was. FTP backup was added with the 4.0 release, and that was more than 10 years ago.
Unfortunately, the new engine does not yet have FTP backup capability. We will update that capability with SFTP (WebDAV would be nice, too) and make it available in a point release in the near future.
From Jay:
my biggest problem with the current version of Retrospect is the performance when doing the initial file scan, not performance writing to the backup device.
I have one Intel Xserve with about 300GB of data on it which currently takes approx 3 hours to do the scan, followed by 1-2 hours to write the backup...
How is performance on scanning looking?
Scanning is faster and uses fewer system resources. I'll see if I can post some performance data here before Macworld Expo.
Here are a series of questions from Maurice:
Will I be able to make report rules that tell me if a system that should be getting backed up hasn't had one in x number of days? Will I be able to make a report rule that can actually check on backup scripts to let me know there is some misconfiguration that's preventing it from running?
Yes and yes.
Where you display dates, I'd suggest following Eudora's idea of naming the last seven dates rather than displaying date itself.
This won't be in the beta, unfortunately, but we hope to get it in the final release.
A minor quirk: I don't think there's enough room to display double digit hours, for example, 12:30 PM.
On the adding client screen, the default display should display the full name of the system—no ellipsis—and its DNS name. They don't always match. The IP address should be shown in full without any ellipsis. Don't we all have big-screen monitors?
Columns are resizable and reorder-able, and many views allow you to turn columns on and off to meet specific needs. This may be one of the most useful features of the new UI: It's all customizable. Check it out:
I can't see scrollbars on the right side of the Sources pane, but from the looks of it, the default should be display way more sources at once.
Not only will there be scroll bars where you expect, but the entire detail view (in the lower half of the window) can be collapsed/hidden.
How will I easily be able to assign, say, 50 computers to a "source group"? It seems as if I'd have to manually enter a tag for each system. Also, how can see every system in a particular group?
Tagging, which replaces Source Groups, won't be completely implemented for the beta, nor will multiple source selection. But they'll be in the release, and you'll be able to assign tags to multiple sources.
From David H:
I think the backup to disk options are a big issue, and all your screenshots here are eye-candy, which do nothing to reassure me that fundamental issues with Retrospect will be actually resolved. Until such time as I don't have to deal with Retrospect flat-out INSISTING that a backup set begin with "1-" , I'm done with this program. That and scripts that are written (!!) to use (for example) "media 1" rolling over to use "media 2" and then failing when "media 2" is not found...
Retrospect 6.1 for the Mac doesn't really have true disk-based backups; it either uses the Removable Disk Backup Set, which forces erasing and renaming of each disk, or it uses the File Backup Set, which places everything in a single file structure.
The new release has true Disk Media Sets, which allow you to keep disks named whatever you want and back up to folders contained therein. You can add members (essentially folders on local or network-attached volumes) to a Disk Media Set, and as long as one with free space is available, the backups will run. The new Retrospect also has a "Skip to blank media" option for folks who use tape and other removable media.
From Marcel:
Will Retrospect finally run as a server process?
As I mentioned above, yes it will, but it doesn't hurt to mention again, since this is the single largest change from 6.1 (and anything we have for Windows, for that matter).
The new Retrospect has three components:
1) the Retrospect server (engine), which runs as a daemon;
2) the Retrospect console (user interface), a Cocoa application; and
3) the Retrospect System Preference pane, which can start/stop the server.
While it's certainly valid for all three components to be installed on the same Mac (that's how I'm using it right now), this architecture also allows the Retrospect server to be installed on one computer, while the console is installed on an entirely different one. This allows a consultant who runs the backups for several clients to manage their Retrospect servers in a single window. Very powerful.
Now, this architecture also changes how things work, even on a single Mac. For example, we can't use the standard Open/Save dialog boxes, since the Retrospect server we're controlling could be across a network, and that's where you need to browse through files and folders. So take note: It's going to feel different.
From Fred:
...can I make a plea that the configuration files are text based rather than binary files? Several times these have got corrupted and I have had to start over from scratch...
The settings for the Retrospect console are contained in a standard plist file. The Retrospect server, however, still uses a binary config file. While this is something we'd like to maneuver away from and hope to do so in the future, you will find that the new config file is far less likely to become corrupted.
Two from Erik:
Retrospect 6.1 doesn't seem to be capable of handling more than 12 tapes in a single library. It will choke as soon as it tries to scan the library after I insert the 13th tape.
You will find much improved support for tape libraries, including much better scanning, automated drive cleaning, and support for multiple drives in a library (the latter with an Advanced Tape add-on).
While Retrospect 6.1 is performing a backup or restore operation, it will prevent any other actions from being done within the Retrospect software. For instance, while I am overseeing a lengthy restore, it would be nice to be able to prepare the next restore operation, or indeed be able to restore from one tape library while backing up to another.
This, you will be able to do with ease. This new version of Retrospect has complete support for handling multiple streams of data.
And finally, two from Matthew:
Email notifications. I want to be able to set triggers for email notifications to be sent to my admin email address. Triggering events may include successful backups completed, errors, timeouts for accessing remote items and timeouts for waiting for new media to be mounted (say, a 3rd member to a backup set).
Email notifications aren't going to be hooked up in the beta, though you'll see the options in Preferences:
Look for more email options in future releases.
Setting auto-timeouts. If I run a backup server, for instance, I want to be able to set a time for the server to give up on a client if it loses communication. Like, say, wait 20 minutes, if the execution remains stalled, abandon.
This is a fabulous request, and I know it has been asked by others as well. The only reason we haven't added that as an option for standard backup scripts is because Proactive Backup scripts (called Backup Server in 6.1) has a "Retry failure after n minutes" feature. So if a connection drops, Retrospect waits that amount of time and tries to hit that machine again until the backup is successful.
Still, I'd like to see an option for this. We'll see what we can do.
This post ended up being a little longer than I expected, but I hope that everyone finds some useful info here.
Happy New Year, all.
-Eric