On Sat, 2 Dec 2006, Vim Visual wrote:
> I'll answer point by point
OK. This is 'easy'.
I propose the following:
DO THIS ONCE: (for loose meanings of "once")
mount the USB disk partition that you intend to use to hold
the encrypted data
mount /dev/sd4d /mnt
On the USB disk, create a file large enough to hold your data forever.
Say, 6GB. This file stays on that disk "forever".
dd if=/dev/prandom of=/mnt/bigfile bs=1000 count=6000000
associate that file with a svnd with vnconfig
vnconfig -k svnd0 /mnt/bigfile
newfs that svnd
newfs /dev/rsvnd0c
Note it could have been disklabel'ed into many partitions, if
needed or wanted. But this works.
umount the usb disk.
DO THIS EVERY TIME YOU WANT TO USE THE SYSTEM IN THE FUTURE.
mount the usb disk (mount /dev/sd4d /mnt)
vnconfig bigfile
vnconfig -k svnd0 /mnt/bigfile
mount the svnd filesystem
mount /dev/svnd0c /home/vim/archive
... time passes ... backups are maybe made ...
Time to go home?
umount /home/vim/archive
vnconfig -u svnd0
umount /mnt
TO MAKE BACKUPS
Use rdist. With a clever distfile (input file to rdist), only files
that are altered since the last time are fussed with. Files that
are deleted from the working directories are deleted from the
archive.
Here's a sample distfile that I have used in testing:
#File for mirroring /home/vim stuffs
vim: /home/vim/data -> [EMAIL PROTECTED]
install -oremove /home/vim/archive ;
EOF
You would run rdist by saying "rdist vim"
This assumes that the stuff you want archived is the entire directory
tree under /home/vim/data, and that you would like it all mirrored
under the directory tree /home/vim/archive
So if you have a file
/home/vim/data/February/testsim.out.bin
and you run the rdist program, you'll then have a file
/home/vim/archive/February/testsim.out.bin
That latter file will be encrypted ;-) so will its directory name.
They are on a file system newfs'ed inside the file /mnt/bigfile.
No information about the filesystem is visible without vnconfig'ing
it with the proper password.
I'm making some scripts. This'll work, and it will be automatic.
It will be easy to write a cronjob to run rdist out of a shell
script... the shell script should test for the existence of
/mnt/bigfile, and maybe also for a dummy file in /home/vim/archive/,
if both are present, it can run. (Maybe someday you want to run
this on a thumb drive etc at home or on the road to take a backup.)
I've half-tested this stuff. All the concepts are correct. Rdist,
as far as I know, is a very reliable, audited, decent program. Read
up on rdist, man rdist. You can get *real* cute in writing the
distfile, the list of commands for the backup. By default rdist
just looks at date/time/size (I think) to decide whether to backup
a file or not. This cuts down on the amount of time-consuming disk
I/O (USB is slower than ULTRA-SCSI 3 ;-) and crypto in the kernel.
(To compare a cksum, the kernel would end up decrypting the existing
backed-up file to calculate the cksum.)
If most of the files never change (data input files), separate them
by directory, and only rdist them if they *do* change, or to start
off the whole archiving project. You can have multiple "labels"
in your rdist distfile.
I think this ought to work. It will be faster and I think more
reliable than tar'ing up a whole mess of stuff and running that
through mcrypt.
Dangers: vnd/svnd depend on OpenBSD. (The "bigfile" *might* port
to some of the other BSDs but I don't know.) To take bigfile, get
the files out of it, decrypt them and copy them to something actually
portable to anything, you will need a functioning O'BSD machine with
a USB device. You should also backup the data on a less frequent
basis to tape or another disk using portable tools (tar, say),
maybe unencrypted and then store in a safe.
Alternative: instead of rdist, use dump. Dump(1) also does
incremental backups on an automagic basis.
Note that all this is done using the stuff that came with OpenBSD
in the default basic distribution. Now that is slick ;-)
restoring a single lost file would involve setting up and mounting
the svnd, and just "cp".
If the laptop gets wrecked, you will need to know the password.
If you use the -K option to vnconfig, you will also need to know the
salt. These things should be stored on paper, (in a bank, if $$
is involved).
Disadvantage: studying the USB disk will show you are hiding something.
The size of "bigfile" will suggest what that is.
Dave
_______________________________________________
Openbsd-newbies mailing list
[email protected]
http://mailman.theapt.org/listinfo/openbsd-newbies
