One pice of meta-advice may be appropriate: Try for simplicity. If you feel your solution is getting too complex to understand it in one go, try very hard to find a simpler one. Complex solutions are not only a lot more likely to fail, the chances for them to be secure are a lot worse. Incidentially, the ooriginal question was about file backups, not snapshots. If you want a snapshot and can afford to umount the device, just use dd. A sector-level shapshot will leak information about which disk areas have been changed (another reason to do file-level backup), but other than that it is as secure as the original partition. Arno On Sun, Nov 01, 2009 at 12:39:47AM +0100, Luca Berra wrote: > On Sat, Oct 31, 2009 at 11:03:02AM -0700, Ross Boylan wrote: >> On Sat, 2009-10-31 at 09:12 +0100, Luca Berra wrote: >>> On Fri, Oct 30, 2009 at 01:05:54PM -0700, Ross Boylan wrote: >>> >Does anyone have any advice about how to snapshot an encrypted volume so >>> >that the snapshot won't leak information? >>> > >>> Do you mean linux-lvm snapshot >> Yes. >>> or some storage based one? >> I'm not sure what that means, but I don't want to rsync or tar. The > i meant a storage devices which presents disk space as one or more lun > to a host using either fibre-channel or iscasi or similar means, but > that's not your case. >> >>> In the first case I think the safest way is encrypting the PV. >> >> I don't think I can. Here's my setup: >> V1E encrypted volume, built on top of >> V1R raw volume, which is part of VGA volume group, composed of >> PVA physical volume (which is actually software RAID). >> > ... >> >> So if I snapshot V1E I think I must use VGA (at any rate, I have no >> other space), which exposes the readable version of my data. > it fails on me when creating the v1e-snap device, but maybe i am just > too tired to figure it out now, see below... > >> Maybe I could snapshot V1R and use the same encryption key as for V1E to >> make V2E? > when i try to luksOpen a snapshot i get "Device Busy" > and "device-mapper: ioctl: device doesn't appear to be in the dev hash > table." in dmesg > >> Now that I think of it, I'm not even sure if LVM will snapshot the >> product of dm-crypt (V1E). > no, you have to do it by hand > it could be something like: > > size=`blockdev --getsize /dev/mapper/v1e` > cowsize=$(( $size / 2048 * 20 / 100 )) # 20% of v1e size > chunk=8 > lvcreate -n v1e-cow -l $cowsize /dev/vga > dmsetup table v1e | dmsetup create v1e-real > dmsetup suspend v1e > echo 0 $size snapshot /dev/mapper/v1e /dev/vga/v1e-cow p $chunk | dmsetup create v1e-snap > echo 0 $size snapshot-origin /dev/mapper/v1e | dmsetup create v1e-origin > dmsetup table v1e-origin | dmsetup load v1e > dmsetup resume v1e > > mount /dev/mapper/v1e-snap /wherever > backup > umount /dev/mapper/v1e-snap > > dmsetup suspend v1e > dmsetup remove v1e-snap > dmsetup remove v1e-origin > dmsetup table v1e-real | dmsetup load v1e > dmsetup resume v1e > > > -- > Luca Berra -- bluca@xxxxxxxxxx > Communication Media & Services S.r.l. > /"\ > \ / ASCII RIBBON CAMPAIGN > X AGAINST HTML MAIL > / \ > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
