[sf-lug] OS image backup (was: ... seeking advice re running Windows (on a Linux OS))

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] seeking advice re running Windows (on a Linux OS)
> Date: Wed, 30 Sep 2020 15:31:16 -0700

> 1.  Non-destructively shrink your Windows partition with one of the
> usual tools, so it's no bigger than it needs to be.
> 2.  Attach a big USB-connected external drive, which I suppose should
> have a big ext4 partition on it.  From a live distro, run the p2v tool
> for Linux to image the Windows parttion to a big honkin' .vmdk file on
> the external USB drive.  This might take an hour.
> 3.  To be totally safe and not risk burning any bridges, extract the
> Windows drive, set it aside as a spare, and put a different blank
> drive into the computer.  (This step can be skipped if one is
> confident, but I wouldn't.)

You know, what I often do - and somewhat regardless of the particular
Operating System (OS) ... at least if it has filesystem type(s) that
Linux can deal with, ... and not necessarily doing shrinking or full
shrinking of the filesystem(/partition...)

Mount the applicable filesystems read-write (rw)
Create a temporary file on the filesystem
fill it with ASCII nulls (dd if=/dev/zero of=... bs=... typically pick a
fairly large block size, something that will be at least an integer
multiple of the largest sector/block/filesystem/erase block size
applicable - often I'll use 4 MiB to be quite safe for that)
Once the file is full and can't write anymore, essentially repeat,
create another temporary file, and do likewise - keep doing this
until one can no longer write any blocks to newly created temporary
file, or one fails to be able to create temporary file at all.
Then sync the filesystem (sync&&sync), then remove those temporary files,
then unmount the filesystem(s) (do same for each applicable filesystem).
One can then make a raw disk image backup of the disk ... one that
compresses quite nicely, as most of the spare filesystem space has
been overwritten with mostly contiguous ASCII nulls.

If the device and relevant layers through the storage stack support it,
discard/trim may be a good or better (and faster) alternative.
Note, however, when taking the compressed image and uncompressing it
and writing it back to drive, the earlier trim/discard benefit will be
lost, as those blocks get overwritten with ASCII nulls.  However one
may be able to regain the trim/discard state after the overwrite has
been completed - as those would correspond to unallocated storage
blocks on the filesystem.

This can also be fairly handily used with VMs and raw disk image
files - notably as sparse files.  With those blocks of
unallocated data as ASCII nulls, they can be made sparse.
E.g.: # fallocate -p -l length_of_file file
Again, discard/trim can be useful - if supported through the
storage stack.

discard/trim ... but do note that drive encryption is being used,
discard/trim can "leak" some information - notably what blocks
don't actually have allocated data (and thus revealing the remainder
which do, or may).