Re: [dm-crypt] expanding encrypted volume/growing the volume

[Robert Nichols <rnicholsNOSPAM@comcast.net>]

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.