[buug] Backups :-) (& CD-R[W], etc.)
Tony Godshall
togo at of.net
Sun Apr 10 22:03:01 PDT 2011
Indeed, very much the tools-you-can-string-together approach of Unix
rather than the tool-that-must-do-everyting approach of VMS or Emacs.
Michael, how would plumb near encryption for an untrusted far store-
some kind of block-device-over-ssh-tunnel scheme?
Best Regards.
On Sun, Apr 10, 2011 at 20:46, Michael Paoli
<Michael.Paoli at cal.berkeley.edu> wrote:
> Yes, rather what I was going to say. It doesn't "do" encryption, but
> it plays nice with it. On the transport side, Bup works very nicely
> with ssh(1), and on the storage side, nothing prevents one from using
> some type of encrypted storage (e.g. encrypted filesystem).
> If one doesn't trust the backup storage side "that much" with one's
> data, the encryption layer can be at or closer to the client side, so
> the backup storage side can just be storage, and the filesystem and
> encryption layer(s) at or much closer to the backup client side, so
> backup server/storage never need store (or have access to) clear-text
> backup data.
>
> As for my backup program
> http://www.rawbw.com/~mp/perl/#backup
> I mentioned in:
> http://www.weak.org/pipermail/buug/2011-April/003759.html
> it doesn't "do" encryption, but again, it plays nice with it. I've
> used part/much of those programs to do backup remotely (over ssh), and
> - not sure if I did it with those programs or not, but also nicely
> added encryption to storage of backups - and easily can with those
> scripts/programs, if I didn't already. In that particular set of
> programs, doing the backup - part of the architecture generates a list
> of filesystems, along with some metadata about them (e.g. filesystem
> type). Another part takes that data, and from it produces a stream of
> backup data - one can easily insert encryption there (I'm pretty sure I
> did so with later version of, or based upon that software), that
> "older" version, from there, just takes that stream of data and handles
> backing it up to the backup media - to the program, it's just a stream
> of bytes, it doesn't particularly care what's in it. It just knows that
> stream of bytes correlates to a particular filesystem, and when the
> stream ends and it's written that data, it then adds that
> meta-information to its index of which filesystems start at what offset
> on what media - and writes the index out at the very end, and to the
> media at the end. Not a very detailed index, but covers to filesystem
> level anyway (other data or indexes that can be added as part of the
> backup may cover more detail, and in some cases, actually do - e.g.
> first thing that gets backed up with that collection is a fair chunk of
> metadata - if I recall correctly, including a list of all the files
> targeted for backup, among other things (like filesystem types and
> sizes, and partitioning and logical volume configuration information).
>
> So ... "plays nice with" (e.g. encryption) is often as or more
> important than "includes".
>
> For quite a while now, I've been encrypting my offsite backups - at
> least most or all of that data, anyway.
>
>> From: "Tony Godshall" <togo at of.net>
>> Subject: Re: [buug] Backups :-) (& CD-R[W], etc.)
>> Date: Sun, 10 Apr 2011 18:16:05 -0700
>
>> On Sun, Apr 10, 2011 at 12:19, Ian Zimmerman <itz at buug.org> wrote:
>>>
>>> Michael> I did also attend the Bup presentation yesterday:
>>> Michael> http://www.weak.org/pipermail/buug/2011-April/003749.html
>>> Michael> ... from that I might be inclined to add a wee bit more to my
>>> Michael> "wish list" of features/capabilities for backup software :-)
>>>
>>> But it doesn't seem to do encryption yet.
>>
>> Well, you can certainly backup over SSH to an encrypted remote drive.
>
>
More information about the buug
mailing list