Volume Number: 22 (2006)
Issue Number: 4
Column Tag: Review

EMC-Insignia Retrospect 6.1 for Macintosh

by MacTech Staff

If you've been around the Mac market for a while, you know of Retrospect. Originally created by Dantz (which was acquired by EMC a while back), today Retrospect is under the brand EMC-Insignia, but it's still the same familiar Retrospect you are used to.

Retrospect 6.1 for Macintosh is designed to automate cost-effective protection for small and medium businesses (SMBs). While lagging behind Retrospect 7 for Windows, Retrospect 6.1 for Macintosh provides a solid backup solution for file servers, desktops, and notebook computers.

Retrospect 6.1 for Macintosh is available in Server, Workgroup, Desktop, and Express editions. The Server and Workgroup editions of Retrospect cater to business environments with a client/server approach. Retrospect Server edition comes with licenses to protect 100 networked servers, desktops, and notebooks. Retrospect Workgroup edition provides licenses to protect 1 networked server and 20 desktops and notebooks. Licenses for additional networked computers can be purchased separately. Retrospect Desktop edition is designed to provide capabilities of Workgroup and Server editions to home users. Retrospect Desktop edition provides licenses for 2 networked computers. Retrospect Express edition is available exclusively with backup devices.

Retrospect 6.1 for Macintosh Server and Workgroup editions can be run on any server running Mac OS X Server 10.1.5 through Mac OS X Server v10.4 Tiger. Retrospect Server, Workgroup, and Desktop editions can be run on any desktop/notebook running Mac OS 9 or Mac OS X 10.1.5 through Mac OS X v10.4 Tiger. Retrospect can be used to protect networked desktop and notebook clients running Mac OS 7.1 or later, Mac OS X 10.1.5 through Mac OS X v10.4 Tiger, Windows XP, Windows 2000 Professional, Windows NT 4.0 Workstation, Windows 95/98/Me, and Red Hat Linux (versions 6.2, 7.1, 7.2, 7.3, 8, and 9). Retrospect provides protection to networked servers running Mac OS X Server 10.1.5 through Mac OS X Server v10.4 Tiger. Retrospect 6.1 for Macintosh Server, Workgroup, and Desktop editions are compatible with backup devices including hard drives, removable drives, CDs/DVDs, FTP servers, and tape drives. Retrospect Server and Workgroup editions also support tape autoloaders and libraries.

The minimum hardware requirements to run Retrospect are a Macintosh G3 or better and Mac OS X version 10.1.5 or later. Retrospect Desktop edition requires minimum of 128 MB RAM (256 MB recommended). Retrospect Workgroup and Server editions require minimum of 256 MB RAM (512 MB recommended). Retrospect also requires a hard drive with a minimum of 200 MB free space. But, let's be real. You want at least a G4 running this software, with a reasonable amount of RAM. And, while Retrospect does run on earlier versions of Mac OS X, we strongly recommend that you work with at least 10.3 especially if SCSI is involved. In the end, you need to assess your needs and adjust appropriately.

In case you are used to AppleTalk support, note that the most recent versions of Retrospect work on TCP/IP, not AppleTalk. Not a big deal for most, but important to some with older systems. You need to have TCP/IP on each machine, even those on Mac OS 9.

A backup set is the basic building block of Retrospect, which comprises one or more disks, tapes, or discs, or a file or FTP site. The various types of backup sets that can be used with Retrospect are tape backup sets, CD/DVD backup sets, removable disk backup sets (Zip, Jaz, SuperDisk, DVD-RAM, MO, as well as USB and FireWire hard disks), and Internet backup sets. For a backup, the source is generally a hard drive or a folder on a hard drive (Known as volumes and subvolumes respectively).

In our test scenario, we backup to multiple media: disk, over the Internet, and to the SDLT II SCSI-3 drive. This variety of scenarios, along with ease of use, is the type of thing that Retrospect excels at.

Retrospect uses an archival method of backup that ensures backed up files are not deleted or written over until requested by user. Retrospect touts their patented IncrementalPLUS technology to perform backups, which copies only files that are new or have changed since the previous backup to the same backup set. There is no need to specify a "full" or "incremental" backup. Retrospect, by default, copies only the files it hasn't already backed up to the destination backup set. Retrospect uses a catalog file (stored on hard disk) to track the different generations of modified files in a backup set. The catalog enables a search of files eliminating the need of searching the backup media itself. (This is one of the places that you really want to have processing power and RAM.)

Retrospect's usage of IncrementalPLUS backups may result in several versions of a file scattered among several backup sessions within a backup set. This makes for faster backups, but it is a bit of a pain when you do a restore as you'll have to insert every tape, one at a time. Frankly, it's the right way to do this otherwise backups would take forever and you'd be changing tapes all the time during backups (much worse)!

A list of all versions of all the files in the backup set would be overwhelming. To avoid this problem, every time a backup is performed, Retrospect places a "Snapshot" of the source volume in the backup set. A Snapshot is a list of all files and folders on a volume when it is backed up. For each volume, one Snapshot is stored in the catalog and a copy of the same Snapshot is stored on the backup medium. The old Snapshot is replaced with a new one after each successful backup operation. Old Snapshots on the backup medium are not deleted. Retrospect can use a Snapshot to restore, in case restoration of a backup is required. Snapshot can also be used as a guide to see the volume as it was at a given point in time, and then pick and choose individual files to restore. This is some of the most powerful stuff that Retrospect has to offer, and a reason that Retrospect can be used in so many different ways.

Retrospect Clients can extend the backup and restore capabilities of Retrospect to other computers on a network. Retrospect can back up clients on the network without the need for installing file servers, starting file sharing, or mounting volumes. Retrospect's Backup Server offers scripted backups, which prioritizes the volumes most in need of backup and copy their files to the available backup set containing the least current data. Backup Server technology is suitable for environments in which mobile computers and removable disks irregularly appear on the network. Retrospect client users can even initiate backups of their volumes. A Backup Server script is often used along with regular backup scripts to produce an elaborate backup strategy.

Retrospect 6.1 for Macintosh provides a number of ways to protect and restore data including two basic categories of operations: immediate operations and automated operations. Immediate operations are initiated manually and executed immediately. They include backup, archive, restore, duplicate, and transfer. Immediate operations can be automated by creating scripts. These scripts automate the repetitive tasks of these operations. Retrospect offers three ways to create scripts: the EasyScript Wizard, scheduling an immediate operation and using the Automate>Scripts command.

Retrospect uses hardware intensively, to transfer large amounts of data between a source volume, such as a hard disk, and a backup device, such as a tape drive. As you might imagine, Retrospect is the "king of drivers", and is able to communicate with hardware devices using a wide variety of technologies including SCSI, Fibre Channel, ATAPI, FireWire, and USB. Retrospect supports Fibre Channel tape drives and tape libraries using Point-To-Point, Arbitrated Loop, and Switched Fabric topologies.

One of the things that we wanted to tackle in the test article is backing up telecommuters and satellite offices. There are a variety of ways to do this that we experimented with: mounting volumes over AFP, FTP, backing up a remote client and more. In the end, the way that worked best was to use Retrospect Server to push data to Retrospect Client rather than the typical pull data from the client. In other words, normally the server is attached to the storage device for the backup. You would pull data from the client to the server, and store it on the tape or hard drive attached to the server. In "push" methodology, you would use the Retrospect Server software to push data via the Retrospect Client installed on the backup server where the backup stored. Seems a bit unusual, but it works great.

Depending on your setup for a remote install, you could simply have your Retrospect Server talk to the client over the Internet, and that will work fairly well. The one issue with this is that your Retrospect Server will not be able to work on anything else until that backup is done. We chose to avoid this as our backups would not be able to finish overnight in the test scenario.

A second approach would be to use FTP or AFP to mount the volume, and then write to it. While this approach can work, it's not particularly resilient to poor Internet connectivity issues, and more importantly, it is painfully slow over moderate net connections like DSL or cable modems. The slowness is really not about the copying time, but the scanning time. It is very slow to scan a remote machine mounted on the local desktop.

The approach that we ended up with was to install Retrospect Client on the backup server, and then use Retrospect Workgroup to copy the data from the remote office up to the backup server using the Client on the backup server. Feels a bit backwards at first, but it works great and transparently. In fact, we went one step further and had a workgroup server running Retrospect Workgroup at the satellite office, copying relevant data on each machine in that office to the workgroup server (in other words, do prep work by consolidating all the data that we wanted to backup to one folder). Then, we "upstaged" that data from the prep folder to the main backup server by running Retrospect Workgroup at the satellite office, and using Retrospect Client on the main backup server.

The telecommuter that we had in the test network would do the same thing as the satellite office, but only one would work at a time (given that currently, the Retrospect Client can only talk to one server at a time.) The cool thing is that the second network backup will just sit and wait until the Client is ready. So this works fine.

Doing this allowed us to still make daily backups (and snapshots) to tape on the main backup server, and gave us a very powerful backup solution.

If you do set things up in this way, we strongly encourage you to use Retrospect's "Link Encryption" so that what you send out over the Internet is encrypted. On slower machines, working exclusively within a LAN, this could have a performance impact. But, over the Internet, the bottleneck will be your net connection.

One last thing: we found it useful to have the backups coming in over the Internet to go over the second Ethernet interface so as not to take anything away from the LAN backups. We did this with a separate IP address, and at times, we even did traffic control to move this traffic over our backup connection at the main location (instead of the primary location).

One issue that we ran into with Retrospect is live files. In our case, one of our Xserve's is a live web server and runs MySQL. As you might imagine, MacTech's web site gets more than a little bit of traffic, and the MySQL server is hit constantly for a variety of reasons. Whenever Retrospect would back up this machine, it would literally bring the Xserve to its knees and we would have to restart the Xserve to recover.

To get around this, we had to "exclude" MySQL files from the backups, and use something different to back them up (see Navicat article). And, as we mentioned in the overview article, we made sure that any of the database servers (FileMaker, Now Up-to-Date event server, etc...) all used their own method of backing up a database to the local disk. Retrospect would just back up those snapshots when it backed up that server.

One of the nice things about Retrospect is that it does support a variety of different OSes. While that may not be as extensive as other applications on other platforms, if you are primarily a Mac network with some Windows machines on it, you'll have no problem running Retrospect Server on your Mac.

Be careful about updating your Windows client machines if you are using Retrospect Server on the Mac to back up those machines. The Windows version is ahead of the Mac version as we speak, and you could run into capability issues if the Windows version gets too far ahead of the Mac version.

We've always told people "don't backup what you can afford to lose." Of course, we were trying to drive a point home on the importance of backups. But you should really take this a step further: "don't keep an offsite backup for anything you can afford to lose."

The next question is what is the best approach. Some people have one backup set (e.g., a set of tapes) for each day of the week. In our test case, we found that the tapes held so much data that we could take a different approach and not changes tapes often. In that approach, we simply use two sets, and keep one off site at all times. We switch them once a week, so our off-site backup is never more than a week old, and we retire sets every 3 months to keep the tapes maximally fresh, and tape sets small.

You need to find the mix of rotations, and retiring backup sets that works best for you. It will definitely take some experimentation as there's a nearly infinite number of ways to go.

If you are looking for easy to use, easy to set up, and a tried and true solution for small and medium size businesses, or even at home, Retrospect 6.1 is a great way to go, and we recommend it wholeheartedly.

Retrospect Server v6.1: $799.00

Retrospect Workgroup v6.1: $499.00

Retrospect Desktop v6.1: $129.00

Available from: http://www.emcinsignia.com/

MacTech Staff