Jason Boxman wrote: > Of late, I have been pondering taking additional steps to safeguard my data. > Currently, I have Dirvish running once a day, whatever the Debian package > default > cron is set for. I am thinking about several additional steps. > > 1) Running an hourly for more crucial data > > The volume in question is on a LVM2 LV, so I was considering doing a snapshot > prior to backing up the data, perhaps in a pre-backup client script?
My cron job is a wrapper script around dirvish and dirvish-expire. First it mounts the backup drive, possibly starting luks/dm-crypt if needed, then uses ssh to each server to run a remote script which creates the snapshots. Actually, it unmounts and removes last's nights snapshot and creates a new, updated snapshot and mounts it. This allows my users to retrieve files that they just deleted without consulting me. Then the script runs dirvish-expire, follows by a dirvish series of dirvish command. The last step is to unmount and possibly close dm-crypt/luks devices. I don't use dirvish-runall because I am unaware of a way to control which vaults are run. I have different schedules for certain less critical vaults. Might need to be a future feature of dirvish-runall. I can post my script if anyone's interested. > > I don't want to backup the entire host hourly, as I do so nightly anyway. > Would I want to create an entirely new 'host' for handling this, or would it > make > sense to finally investigate the branch feature of Dirvish, or some other way? I create a separate vault per partition per server and, in some cases, multiple vaults per partition. I use xdev and exclude to ensure that there is no overlap in backed up data. I recommend putting data that is backed up more often into it's own vault and just running dirvish on that vault as appropriate. I have never looked into branches and am not sure when they would be used. > > 2) Snarfing up crucial data and shipping it off elsewhere > > Somewhat outside the realm of Dirvish, but what might be some viable ways of > dealing with accounting files, SSH and GPG keys, and other critical > organization > data that ought to be located in additional locations off-site? Such a step > could possibly be integrated into a post-server script, depending on the > nature > of it and level of automation possible. (A USB stick or DVD-RAM might need > manual intervention, for example.) I use external USB or E-SATA hard drives for all my backups as DVD are two small and inflexible for my needs. For all backups going off-site, I first encrypt the entire partition using LUKS. LUKS allows multiple types of keys for decrypting the drive. I have a key file which is stored on the backup server for automatic mounting, and a strong passphrase which I have memorized as well as written in a few secure locations such as my Will. A stolen backup drive should not reveal any useful information. > > 3) Integrating additional storage on Windows hosts > > I notice modern Windows desktop systems generally ship with a huge amount of > additional storage that is completely underutilized. While entirely outside > the > scope of Dirvish, I am curious if anyone has integrated the extra space into > some > kind of backup routine. Site security certainly plays a role here. In my > organization, each system could have backup data without the concern of > locking > down each system to hide backup data from the user. (Small office, family > business, ect.) Since Windows does not use a POSIX compatible filesystem, dirvish will not be able to backup the files meta-data so it depends on how much that is valued. Biggest problem is permissions will be lost. Other backup systems are not dependent upon the underlying filesystem being POSIX compliant, but do not provide the ease of access to data dirvish does. > > I was pondering if some way existed to have the Windows box reboot at a > scheduled > time and run some alternate boot option that brings up, say, a GNU/Linux > distro > that can standby for the appointed hour where data is either pushed or pulled > to a partition containing extra space. After, the system can initiate a > shutdown > and be available in the morning for power-on, as per usual. (Kind of out of > left > field, but something I dreamt recently.) There are ways of remotely initiating a shutdown or reboot on Windows, however, I have never done it. NTLDR, Microsofts bootloader, can boot start Linux booting as an option. Wubi, which installs a copy of Ubuntu Linux onto a Window partition, uses NTLDR to choose whether Windows or Linux is booted. The default is specified in C:\boot.ini which can be edited in Windows to change the default to Ubuntu, and in Linux to change the default back to Windows before shutdown. I would not recommend this approach, but it is theoretically possible. > > Thanks. > > > > > > _______________________________________________ > Dirvish mailing list > [email protected] > http://www.dirvish.org/mailman/listinfo/dirvish > -- Loren M. Lang [email protected] http://www.alzatex.com/ Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc Fingerprint: 10A0 7AE2 DAF5 4780 888A 3FA4 DCEE BB39 7654 DE5B
begin:vcard fn:Loren Lang n:Lang;Loren org:Alzatex, Inc. adr:;;6400 SW 213th Ave.;Aloha;OR;97007;USA email;internet:[email protected] tel;work:503-649-9693 x-mozilla-html:FALSE url:http://www.alzatex.com/ version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Dirvish mailing list [email protected] http://www.dirvish.org/mailman/listinfo/dirvish
