Epilogue mentions dding from within the VM as a possibility – the gdb method described in the post is definitely a better solution though, because by stopping the VM during the copy you get an atomic snapshot of the whole block device, whereas a dd from inside it (while it was running) could leave your resulting disk image with potentially-nasty filesystem inconsistencies.
Another problem with dd that I didn’t have time to mention is that the default for virtualbox images is dynamically allocated. So a dd could result in a much larger file.
Believe it or not, I’ve had the opportunity to “dd if=/dev/vda of=someotherdisk” in a live system without much issue. The secret? - I simply limited the processes that could write to the disk and did an fsck on the actual file.
I don’t recommend doing it… It’s living life on the edge - But sometimes it is necessary if you are unaware of alternatives.
Why not ignore the block device problem entirely - attach a new disk and rsync -a / /newroot
A few things occur to me:
True. You’d definitely have to reinstall your bootloader, re-whack at partitions, etc. But “oops I destroyed the backing file” is firmly in disaster recovery territory, so c'est la vie.
it’s still not atomic
shutdown now (or I think /sbin/init 1 on Linux) leaves me with init and a shell. Nobody’s gonna mess with the FS. But mount -u -r to be sure.
mount -u -r
As for hotplug, you could just use USB passthrough and dump to an external drive if your hypervisor doesn’t support it.
Don’t get me wrong - this is a nifty hack for sure. I just think if you’ve got data that you really care about you should use tools on the guest to safely recover it.
Freezing the world with gdb means you get a perfect atomic snapshot of the block device, but it doesn’t prevent you from freezing the VM right as the kernel is in the middle of shuffling data around… or poking at the superblock that handles the crypto for your disk. You might get a perfectly broken snapshot.