I see. My solution to a similar problem is rsync, a very smart mirroring tool, but I don't think that it supports encryption. rsync is primarily designed for mirroring over slow connections, but it also seems to keep redundant servers in sync with minimal effort. Whatever works; there's often more than one right answer... On Friday 24 August 2001, Christopher Maujean <[EMAIL PROTECTED]> wrote: > The loop device and the file-system-in-a-file is useful for on the fly > encryption and a host of other things. The point is not really to use it > like tar, but to actively run it. Do you think it will be faster to: > > (every night) > tar ,gzip, encrypt (with blowfish or twofish or idea /etc, ftp it to > another machine, unencrypt, tar, gunzip it, > or > (once) > dd a file, mount it via loop as /etc on two different machines > > (every night) > unmount /etc > gzip /etc.raw > ftp it to another machine > gunzip > unmount the old /etc > mount the new one via loop. > > > There are drawbacks, its gotta be a tiny bit slower to use the file/loop > partition without encryption, and more than a tiny bit slower with, but > the advantage in ease of (backup, security, replication) makes up for > that to me. > > *NOTE* > I have not implemented all of this yet, but the above reasoning is my > excuse to test cool, non-mainstream features of my favorite OS. > > --Christopher > > On Fri, Aug 24, 2001 at 04:20:12PM -0700, Ralph Zeller wrote: > > Chris, > > > > This isn't really much different than a tarball, though, which would > > assure better individual file integrity. That is, why is using the > > "dd" technique more useful than: > > > > tar -cvf myarchive.tar /etc > > gzip myarchive.tar > > > > (I'm asking the question above because I don't know) Maybe you are > > borrowing diskspace from a vfat drive? > > > > I like to use dd to copy (mirror?/ghost?) a whole filesystem. For > > instance, if it was the goal, we could set up a "model" linux system > > for efn, then boot tomsrtbt, mount an nfs filesystem and dd the local > > linux partition to a file on a bigserver. > > > > After booting the blank clone system with tomsrtbt, and mounting the > > bigserver share, fdisk, then something like > > dd if=/mnt/bigserver/archive.img of=/dev/hdb2 bs=4M > > mount the image, chroot, lilo, change ip's, done. > > > > Better yet, if the hardware is similar enough you can get away with > > this on the model pc: > > dd if=/dev/hda of=/mnt/server/myimage.img bs=4M > > > > and this on the clone pc: > > dd of=/dev/hda if=/mnt/server/myimage.img bs=4M > > > > Poor man's ghost? Hey, it works! > > > > Ralph > > > > At 04:57 PM 8/22/2001 Christopher Maujean <[EMAIL PROTECTED]> wrote: > > >interesting. > > >i did: > > > > > > mknod /dev/loop22 b 7 0 > > > dd of=/tmp/archive if=/dev/zero bs=1024 count=65536 > > > /sbin/losetup /dev/loop21 /tmp/archive > > > mkdir /archive > > > /sbin/mkfs /dev/loop22 > > > mount /dev/loop22 /archive > > > cp -r /etc /archive > > > unmount /archive > > > cd /tmp > > > gzip archive > > > # it was just over a meg, gzipped > > > # ftp'd it to another machine.. > > > # mknod'd, gunzipped, mounted > > > > > >I knew it worked as emergency swap. but, backup could be a cinch. > > >I could make a set of backup files, one for each backup period. > > >operate on them as I would a standard partition, gzip and write > > >them to tape or cd. > > > > > >am I missing some important part of the equation? is there something > > > wrong with my logic, do people already do this kinda thing all the > > > time? do people not do it because of something I'm missing? > > > > > >On Wed, Aug 22, 2001 at 03:46:15PM -0700, Christopher Maujean wrote: > > >> Does anyone know how much of a performance hit one would take using > > >> a > > > > dd'd file > > > > >> via the loop device? is there any performance hit? > > >> > > >> ReverendTrance > > >> > > >> > > >> -- > > >> > > >> Christopher Maujean IT Director Premierelink > > >> Communications [EMAIL PROTECTED] > > >> www.premierelink.com > > >> ------------------------------------------------------------------- > > >>--- GnuPg/PGP: 0x5DE74D38 > > >> Fingerprint: 91D4 09FE 18D0 27C1 A857 0E45 F8A4 7858 5DE7 4D38
