On 09/10/2014 03:36 PM, Ross Boylan wrote:
On Wed, Sep 10, 2014 at 08:25:07AM -0500, Robert Nichols wrote:
The snapshot LV can increase its size only if you created it as thinly
provisioned, and even then it can grab extents only within the LV that
you set up as a "thin pool" LV. The space within that thin pool LV is
not "free" for the purposes of creating a new LV. Creating a new LV
with "--extents 100%FREE" will not affect expansion of your snapshot
LVs.
Good; I didn't do thin provisioning.
Game Plan (for IMAP server and its spool):
## Verify that backups are OK
## randomize free space in LVM volume group turtle
lvcreate -l 100%FREE -n tozero turtle
cryptsetup open --type plain -d /dev/urandom /dev/turtle/tozero zero_crypt
dd_rescue -w /dev/zero /dev/mapper/zero_crypt
# free space ~ 100G--likely to take awhile. Hours? days?
# if it's really slow I could allocate 2 LVs, one of which is the size
# I need ~50G, and the other of which is filler. randomize the 50G;
# free the space, and extend my volume.
cryptsetup remove zero_crypt
lvremove turtle/zero
## make encrypted spot to backup recent files
# /usr/local/backup is not encrypted. Assume I create a small encrypted volume
# and mount it at /usr/local/backup/crypt
## shutdown server
## backup current server state
# do manual backup of selected server state
# If possible make a backup of the directories the usual way.
# Otherwise, as root
cd /usr/local/backup/crypt
# snapshots at 00:10 daily. Assume current day has not
# been backed up yet.
tar cjf cyrspool-recent.tar.bz2 --after-date 'Sep 9 00:09 -0800' /var/spool/cyrus
## take directory offline
umount /var/spool/cyrus
cryptsetup luksClose cyrspool_crypt
# maybe close snapshot of turtle/cyrspool before extending?
## Actually grow things
lvextend -L +20G turtle/cyrspool
cryptsetup --key-file xxx luksOpen /dev/turtle/cyrspool cyrspool_crypt
resize_reiserfs /dev/mapper/cryspool_crypt
reiserfsck /dev/mapper/cyrspool_crypt
mount /var/spool/cyrus
## restart IMAP server
I haven't gone over that with the proverbial fine-tooth comb, but it looks
reasonable. I would expect the initializing of 100GB to take on the order
of 20 minutes (100GB at ~85MB/sec -- a decent CPU and internal disk should
sustain that easily).
Yes, I would merge the snapshot back into the base volume and close the
snapshot before extending the filesystem. Otherwise, the enlarged
filesystem structure will exist only in the snapshot. I suppose an
alternative would be to merge the current snapshot, start a new snapshot,
and the enlarge the filesystem. If anything went wrong during the resizing,
you could just discard the snapshot and be right back where you were with
the filesystem. Merge that snapshot once you've determined that all went
well.
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
