Hi, On Wed, Aug 08, 2018 at 07:22:06AM +0100, Murray Crane wrote: xen-shell> rescue rescue $ sudo mount /dev/xvda1 /mnt rescue $ sudo tar -C /mnt -zcvf - . | ssh you(a)other.host 'cat > my-vps.tar.gz' xz is generally better than gzip compression. I haven't checked if the tar in the rescue VM supports that though. rescue $ sudo tar -C /mnt -Jcvf - . | ssh you(a)other.host 'cat > my-vps.tar.xz' Or: xen-shell> rescue rescue $ sudo pv /dev/xvda1 | xz -1c | ssh you(a)other.host 'cat > xvda1.img.xz' I forget if pv and xz are installed in the rescue VM by default. If they aren't you can install them, or else lose the progress display and have worse compression by just using gzip. xen-shell> rescue rescue $ sudo gzip --fast -c < /dev/xvda1 | ssh you(a)other.host 'cat > xvda1.img.gz' Only use high levels of compression if your bandwidth is low or you are really tight on space in the destination. Forcing high levels of compression with gzip or xz doesn't tend to result in much smaller output but does make it take much longer (use more CPU). If you don't want to shut the VPS down while you are doing this, you can send a support ticket asking for an LVM snapshot of your block device. I will attach it read-only to your VPS as a new block device, then you can do the above in your VPS. Since this does not allow applications to save out whatever data they may have in RAM, restoring from a disk snapshot can result in corruption. It is similar to booting after a power cut or kernel panic. Images of block devices can be mounted (after decompression) by using a loop mount: # mount -o loop /path/to/xvda1.img /mnt Are these examples worth adding to <https://tools.bitfolk.com/wiki/Rescue> ? Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting