Back From The Pile: May 30, 2009 – Stephen Foskett, Pack Rat

Back From The Pile: May 30, 2009 – Stephen Foskett, Pack Rat — Sat, 13 Jun 2009 13:20:09 GMT

Pingback from Back From The Pile: May 30, 2009 – Stephen Foskett, Pack Rat

re: When Is A Copy A Backup?

sfoskett — Wed, 03 Jun 2009 20:19:54 GMT

Great comments, Sam! Indeed, the fact that many copy-based backups leave data in its native format is HUGE. This is true for everyone, from the home user to the enterprise with e-discovery.

re: When Is A Copy A Backup?

Sam Srinivas — Wed, 03 Jun 2009 19:36:01 GMT

To fully realize the benefits of a copy-based backup you should be able to able to fully decouple yourself from the actual backup software you are using to make that backup.

In other words, you should be able to able to say "Today I ditch vendor X and switch to Y" and the copy-based backup made by Vendor X should still be useful.

This is certainly true of Time Machine and and Maxtor's One-Touch -- because the only common denominator is on more long life things such as the Apple File System or the NTFS file system.

For example in the One-Touch, you do have the current state of the file system available as a copy with reverse increments for previous states **all stored as full files** -- with not too much effort you can recover the full state of a file at an earlier time without needing Maxtor's software. Many of the One-Touch competitors seem to do similar stuff, which is very good.

This non-dependence on vendor is just taking the basic advantages of open standards (which tend to live long) into backup.

By the way, Mozy certainly does *not* fit this bill -- the data might appear to you as just a file system when you explore it locally, but you don't have physical access to the data as a regular file system -- not only is the data owned by them physically, its in some custom format that you have no visibility into.

Moving to another issue, as you say, a critical requirement of backup is offsite backup. And with copy based backup, offsite backup is reduced to just remote replication.

Ideally you should own the medium which contains the offsite backup -- either a standard file system you own (a disk you actually own someplace) or the new cloud equivalent of that: a standard file system overlaid on something like Amazon S3 which you can read with standard software, not just the backup vendors.

In other words S3 or equivalent is just the equivalent of a low level cloud storage medium, you interact with via a well known file system overlay, which is open not just provided by the backup vendor.

One thing which is missing for remote replication is a standard way to encrypt the backup while preserving the advantages of an open file based approach. A hybrid way to do this might be to do file by file encryption using a standard such as 'crypt' before shipping data to the remote site -- in other words, the remote data can be decrypted and made into a plain file system replica by using standard "open source" decryption with no lock-in to the backup vendor.