In the lab: SATA D2D backup for desktops

Serial ATA (SATA) disk drives in low-cost RAID arrays and disk-to-disk (D2D) backup are usually thought of as server technologies. Could they also be a magic bullet on the desktop?

By Jack Fegreus

Today, the primary internal storage interconnect on the desktop is Ultra ATA, which evolved from the original parallel ATA interface introduced in the mid-1980s. Ultra ATA maintains backward-compatibility with all previous ATA revisions, using the standard 16-bit-wide parallel data bus and 16 control signals across a 40-pin connector. Even though Ultra ATA uses an 80-wire cable, the 40-pin connector remains the same.

This rigid adherence to backwards-compatibility places significant electrical circuit design constraints on engineers who are attempting to advance data throughput for ATA.

At issue are all of the undesired analog effects associated with a parallel data bus, which includes issues of crosstalk and clock skew.

Designed to replace Ultra ATA, Serial ATA (SATA) uses a 2-wire differential pair to create a single signal path to transmit data in a bit-by-bit series. The bus itself consists of four signal lines per channel and currently sports a 150MBps specification. While SATA hardware does not interface with Ultra ATA hardware, it is fully compliant with the ATA protocol. In theory-at least-that makes SATA software compatible with legacy ATA hardware.

Seizing on the SATA phenomenon, CMS has packaged its D2D BounceBack Professional software package with either a removable or external SATA drive to create its Velocity Series desktop backup solutions for Windows. For our tests, we examined a 200GB external drive unit. This package includes BounceBack Professional v5.4, a 200GB Maxtor SATA drive in an external enclosure, two SATA cables, and a pass-through interface card. The pass-through card provides an external SATA interface for an existing internal SATA controller. Without on-board SATA capabilities, we installed an Adaptec SATAConnect 1205SA controller, which is built on a chipset and driver from Silicon Image. This 32-bit PCI card supports up to two drives and provides for system booting.

We began our evaluation by installing the Adaptec controller and the external Maxtor SATA drive. For raw I/O throughput performance, we were not disappointed. Single-drive SATA performance was on par with that of a single Ultra320 SCSI drive. Running our oblWin-Disk benchmark, which exploits Windows asynchronous I/O capabilities to measure best-case performance, an Ultra100 ATA drive was pegged at 21.2MBps using 64KB data transfers. The SATA drive delivered 48.9MBps. While most enterprise backup packages use 64KB reads and writes, most Windows applications use 8KB I/O transfers. With smaller I/O operations, maximum throughput for Ultra100 ATA was pegged at 14.9MBps and SATA was pegged at 37.1MBps.

Throughput on the SATA drive averaged 233% greater than that of an internal Ultra100 ATA drive, making it comparable to a single Ultra320 SCSI drive.
Click here to enlarge image

While SATA drives provide spectacular I/O performance, they are not devoid of serious overhead issues. Our first encounter with the quirks of SATA implementations came with the installation of BounceBack Professional. This software is an effective D2D backup package with origins rooted in data-recovery utilities for drives in laptops running Windows 95. As a result, BounceBack has a history of dealing with slower low-capacity drives, which made efficiency a prime goal. In a world of where ease-of-use trumps program efficiency, such a lineage can easily make the user experience disconcerting, if not outright confusing.

Once installed, BounceBack appears as a collection of 10 independent programs. Getting to the point of learning how to master those 10 programs, however, can be quite a journey. The problem is directly tied to BounceBack's near obsession with physical drives and the time it took to format a SATA drive with the Adaptec controller. Why are physical drives an important piece of the BounceBack equation? That answer lies with the prevalence of removable drives on laptop systems.

For BounceBack, discovering the presence of a particular drive can define a trigger to start a backup. As a result, the BounceBack Settings utility prominently displays a "Backup Devices" tab and the installation process brings up a screen listing the "Backup Devices." In the normal scheme of backup software, any such list would represent a comprehensive listing of all devices to which a backup could be targeted. This is not so for the list of "Backup Devices" under BounceBack.

Under the BounceBack scheme, the list of "Backup Devices" is a list of all physically attached drives. As such, any drive in this list might also be removable. As a result, any drive on this list can be designated to trigger an automatic backup when that drive is detected as attached to the system. This list is logically linked to the BounceBack Formatter utility, which has a cumbersome GUI that makes it a poor alternative to the native Windows Disk Management utility.

Getting beyond the initial jumbled look-and-feel and quirky logic of the BounceBack GUI, harnessing the power of this package's backup capabilities is an easy process. The magic bullet is the Backup tab of the Backup Setting utility where everything needed to create, customize, and target a backup set is found.

Any collection of folders from multiple logical disk volumes can be aggregated into a backup set. Similarly, any folder within any logical volume-including network volumes-can be designated as the backup path target for that set. This ability to select any folder as the backup target makes BounceBack Professional-exclusive of the Velocity Series bundle-a very flexible and powerful tool for IT to aggregate and manage backups of desktop systems. As part of our testing, we also targeted a large SAN-based volume on an HP NAS 9000 server exported over the LAN for backups.

What's more, backup sets are saved in their native file format: There is no proprietary saveset. While BounceBack does have a QuickRestore utility that supports "One Button Restore," simple file restores are just a drag-and-drop away.

There are also several powerful options to customize the backup set. Since backup files are stored in their native format, it is possible to set BounceBack to automatically synchronize the original files and the files in the backup location. This bi-directional synchronization provides a mechanism to support rudimentary collaboration. Multiple versions of backups are also supported. These can be viewed via the BounceBack Version Administrator. Also, because BounceBack is a backup program, there is a verify option to read and compare each file after it is backed up.

All of the necessary settings for creating and managing a backup can be done under the Backup tab of BounceBack's Backup Settings utility. Any set of folders can be put into a backup set and any folder, including folders on a network volume, can represent the target path.
Click here to enlarge image

Unfortunately it is not the Backup Setting, but the Backup Device window that appears early during the installation script of BounceBack. The goal of the recommended BounceBack express installation script is to go beyond installation and perform an initial system backup as well. This is where our initial experience with BounceBack left a negative impression. BounceBack assumes that it is dealing with a typical naïve home user and proceeds to hold that idealized user's hand in a most clumsy manner.

BounceBack assumes that everyone will initially want to back up the Windows C drive. With the backup set implicitly defined, there is no need to bring up the standard Backup Setting interface. In turn, this provides a dramatic opportunity for the BounceBack installation script to be too clever by half.

In particular, the "recommended" express install option makes the assumption that it should create and format a partition on the backup device chosen for initial backup of the Windows C volume. As a result, the installation script now brings up the Backup Device window, which is linked to the BounceBack Formatter, which deals with physical rather than logical volumes. So if the disk has been preformatted-as is the case for the Velocity Series-the "recommended" installation script will delete the existing partition.

At this point, a reasonable assumption would be that the installation process would create a partition that mirrors the system disk in size. That's not the case at all.

Remember that one of the advanced options under the BounceBack Settings utility is to allow multiple backup versions. As a result, the install script allocates the entire volume, which just so happens to have been the original configuration. BounceBack will then begin to format the drive, and there's the rub.

Using the Windows Performance Monitor during a backup, it became clear that BounceBack was using a variable mix of I/O sizes, rather than fixed 64KB I/Os used by enterprise backup packages. While this limits throughput , more limiting was the fact that our Ultra100 ATA drive had half the throughput capability of the SATA drive. As a result, when BounceBack utilized 64KB reads and writes, maximum throughput was limited to about 18MBps.
Click here to enlarge image

On our system, formatting the 200GB SATA drive with the Adaptec controller was a nightmare. It took 100 hours to format the entire drive. Once we realized the enormity of the formatting problem, we typically created a 25GB partition, which we could breeze a format through in just 12 hours! Clearly, there was an issue somewhere between the system Basic Input/Output System, the SATA driver, and the controller. Later, we installed a PCI-X SATA controller from Silicon Image-the 3124 SATALink. Using this 64-bit controller in a legacy 32-bit PCI slot, our formatting problems were resolved and we were able to format the 200GB drive from CMS as quickly as any other similar-sized drive.

Another such problem occurred when we tried to boot from our SATA drive. The BounceBack Disaster Recovery option creates a bootable copy of the Windows system. When we created such a copy with BounceBack on our SATA drive and simulated a head crash on our Windows desktop, the system immediately booted up off of the SATA drive. Unfortunately, once we logged in under a user name, the first attempt to access the system caused a blue screen dump that pointed to the SATA driver. This problem grew worse using the Silicon Image controller as our workstation would not recognize the physical presence of the controller and drive until Windows loaded.

We should note that our progress under Windows using the Adaptec controller was significantly further than we could get with that SATA controller under Linux. We failed to even install both Red Hat Fedora and SuSE Linux Professional 9.2 with the controller in place.

While the gruesome formatting time has nothing to do with BounceBack, any mitigating facts are far from obvious from the user's perspective: The situation immediately appears to be a BounceBack installation problem. All of this can be avoided by not accepting the default express installation or by not installing the Disaster Recovery option. Nonetheless, it is just as easy to fall back into this formatting trap by assuming that the Backup Device tab is the means by which a backup target is assigned to a backup set.

There is, however, a performance issue that is distinctly a BounceBack issue. Not since the very early days of Windows NT have we seen a server backup package utilize 8KB data transfers. Typically this characterized backup packages moving to Windows NT from Windows 95. As our oblWinDisk benchmark demonstrates, using 8KB I/O requests significantly throttles potential I/O throughput.

Using the Windows Performance Monitor during a backup to the SATA drive, two things become painfully obvious. First, BounceBack is using a mix of I/O sizes from 8KB to 64KB. This limits I/O throughput on the Ultra100 ATA drive to as little as 8MBps. Second, the slower Ultra100 ATA drive regulates the entire process, eliminating any chance of achieving the potential of 50MBps on the SATA drive.

In a Fast Ethernet or Gigabit Ethernet backup scenario, however, network throughput, not 8KB I/Os or an external drive, will be the bottleneck. This makes BounceBack an attractive IT solution for backing up critical corporate data, when that data resides on desktop systems.

Jack Fegreus is technology director at Strategic Communications (www.stratcomm.com). He can be reached at jfegreus@stratcomm.info.

InfoStor Labs scenario


Windows 2000 and XP disk-to-disk desktop backup


CMS Velocity Series

  • BounceBack Professional v 5.4 backup software:
    • Backup sets written in native file formats
    • File synchronization option between primary and backup device
    • Versioning of backup sets
    • Bootable backups via Disaster Recovery option
  • Maxtor 200GB SATA drive
    • External housing and power supply
    • Pass-through SATA card

Adaptec SATAConnect 1205SA controller

  • 32-bit PCI
  • 2-port card supports up to two drives
  • Bootable drive support



  • oblWinDisk v3.0


  • Formatting time for SATA drives was a significant issue with the Adaptec controller.
  • SATA drive throughput exceeded that of an Ultra100 ATA drive by 233%.
  • Unable to run the system from the SATA drive with either the Adaptec or Silicon Image controller.
  • Backups can be performed over a network.
  • Backups written in native file format.
  • BounceBack can synchronize the original files with changes to the saveset.

This article was originally published on December 01, 2004