Backup Central

the hard drive of a friend's machine (MacOS X) died recently. I'm
trying to help him figure out ways of setting up collaborative backups.
Ideally, something like rdiff-backup would work because we could just
keep a running backup of the current state of the machine plus a few
weeks worth of reverse deltas for relatively low bandwidth costs.
Problem being that the data is in plain text. which drew my attention
to duplicity. Unfortunately, it doesn't look like that would work in
quite the same way.

duplicity probably won't work because of the cost of generating new
snapshots and transferring them across the net.

any suggestions for somehow protecting rdiff backed up data on a
friendly foreign machine? After all, I really don't want even have a
faint chance of accidentally tripping across my friends e-mail/documents
etc. and because he has root access on this machine, I don't want him
tripping across my backed up content either.

thanks in advance for replies
---eric

On Apr 27, 2004, at 10:17 AM, Eric S. Johansson wrote:

any suggestions for somehow protecting rdiff backed up data on a
friendly foreign machine?

Two possibilities, off the top of my head --

1. Use an encrypted sparse file image on the foreign machine. This
will let you have a file system that, when unmounted, is a big blob of
a file. (See Disk Utility and "hdiutil" for more details.) However,
you'll have to find a way to mount/unmount the image when the remote
rdiff-backup logs in. You might be able to use ssh "subsystems" to do
this -- see "man sshd_config".

However, I see two holes with this: first, once the image has been
mounted, the files on it are readable to the admin of the foreign
machine. So it's not completely opaque. Secondly, it seems fairly
possible for the connection to die in such a way that the image is
never unmounted -- leaving it open again.

2. Use rdiff-backup to a *local* encrypted sparse image, then use rsync
to mirror changes in that image over to the foreign machine. (Rsync
has a --sparse option that may work well here.)

The obvious disadvantage with option #2 is that you have to store your
diffs locally. It also may require a large diff, since at least parts
of the sparse image are being completely re-encrypted.

Again, I haven't really tried either of these -- just throwing them out
as ideas.

--
John Labovitz Consulting, LLC
http://mac.johnlabovitz.com
johnl < at > johnlabovitz.com
+1 503.949.3492

John Labovitz wrote:
On Apr 27, 2004, at 10:17 AM, Eric S. Johansson wrote:

any suggestions for somehow protecting rdiff backed up data on a
friendly foreign machine?


Two possibilities, off the top of my head --

1. Use an encrypted sparse file image on the foreign machine. This will
let you have a file system that, when unmounted, is a big blob of a
file. (See Disk Utility and "hdiutil" for more details.) However,
you'll have to find a way to mount/unmount the image when the remote
rdiff-backup logs in. You might be able to use ssh "subsystems" to do
this -- see "man sshd_config".


However, I see two holes with this: first, once the image has been
mounted, the files on it are readable to the admin of the foreign
machine. So it's not completely opaque. Secondly, it seems fairly
possible for the connection to die in such a way that the image is never
unmounted -- leaving it open again.

probably acceptable for a friendly backup site.

2. Use rdiff-backup to a *local* encrypted sparse image, then use rsync
to mirror changes in that image over to the foreign machine. (Rsync has
a --sparse option that may work well here.)

The obvious disadvantage with option #2 is that you have to store your
diffs locally. It also may require a large diff, since at least parts of
the sparse image are being completely re-encrypted.

I agree that the most probable killer would be the re-encryption of
large chunks of disk.

although, one could implement this and then use an M-of-N partitioning
model combined with rsync. again, the expected large number of changes
would probably be a killer.

Again, I haven't really tried either of these -- just throwing them out
as ideas.

they are good ideas. I just wanted to see if anybody had thought about
the problem.

the big problem with doing this is an issue of trust. so, the answer
might be to encrypt the files as you send them over and leave the file
hierarchy intact. Unless you start building a file format like tar that
can handle these deltas (encrypted or otherwise), you can't help but
reveal the file hierarchy.

---eric


---eric