1. 18
  1.  

  2. 3

    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.

    1. 1

      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.

      1. 1

        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.

        1. 1

          Why not ignore the block device problem entirely - attach a new disk and rsync -a / /newroot

          1. 1

            A few things occur to me:

            1. That’ll miss outside-the-FS things (like bootloaders and partition tables) that you might want to have around if you’re looking to boot the VM off the new backing storage.
            2. While it would ensure a consistent FS, it’s still not atomic (though if you have a reasonably idle system that’s probably unlikely to cause problems).
            3. A cursory google seems to indicate VirtualBox does support it, but I’m not sure how universal support for disk-hotplug is in general among current hypervisors.
            1. 1

              outside-the-FS things

              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.

              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.

        2. 2

          Another possibility that just occurred to me: OSX has a mechanism to open files by inode number (see http://superuser.com/questions/163941/what-is-the-vol-directory-for), so it might have been a lot easier to just do an fstat on the file descriptor and then ln /.vol/$volnum/$inum /path/to/image (testing on my OSX machine confirms you can create new hardlinks to things in /.vol).

          1. 2

            I actually had the chance to try this out and you can’t open a deleted file on OSX using the /.vol/ folder. As soon as the file is unlinked you get a “No such file or directory” error.