0

Is it possible to fully backup both partitions of Kali on my USB drive to my laptop's hard drive while keeping it functional in the future were I to restore it to the USB? So far I only see methods of restoring the main partition (I'm on Windows and I know it can't detect multiple partitions but I am willing to go into a live linux distro on a secondary USB drive). The reason for this is I would like to use a ParrotOS Live CD with persistence instead but I'd hate to lose all my work I put into configuring Kali.

0

It's quite easy to backup a full USB drive. In Linux a USB drive is available as a block device. Partitions are available as block devices as well. In fact they are just fragments of the drive that holds them. The kernel reads the partition table and provides names like /dev/sdx1 or /dev/sdx2, so you (and processes, and the OS itself) don't have to work with /dev/sdx, to explicitly take the partition offset into account each time or to pay attention if your read/writes are not going to cross the partition boundary.

Every method to backup /dev/sdx2 can be used to backup /dev/sdx. Technically it makes no difference: you read from a block special file and write to elsewhere. Any tool that reads, changes nothing and writes – will do.

In Linux it can be as simple as (pick one):

cat /dev/sdx >/path/to/image
pv  /dev/sdx >/path/to/image
cp  /dev/sdx  /path/to/image

or (not as simple, but quite common example):

dd if=/dev/sdx of=/path/to/image bs=8M

In your case /path/to/image should belong to a mounted filesystem of the hard drive of your laptop.

Copying the entire /dev/sdx means copying the master boot record and partition table (if any), bootloader (if any), all partitions and unpartitioned space.

Make sure the content of /dev/sdx cannot change. If it changes when you read it then you will possibly get an inconsistent image. If you imagine the data on your USB as a picture, an inconsistent image will look somewhat like the panorama fail phenomenon. This happens when you build a large image from sequentially captured fragments that change in the meantime.

Live systems without persistence usually never modify the device they started from, so you could copy such OS even from within. I guess in your case at least one partition gets mounted with write access to provide persistence, this complicates things.

Fortunately you're willing to go into a live Linux distro on a secondary USB drive. It's a very good idea. Just make sure the OS doesn't automatically mount filesystems from the USB drive you're going to read.


Eventually you're going to write the image back. To do this, revert the flow: read the image and write to the device. Examples (pick one):

cat   /path/to/image   >/dev/sdy
pv    /path/to/image   >/dev/sdy
cp    /path/to/image    /dev/sdy
dd if=/path/to/image of=/dev/sdy bs=8M

Notes:

  • It's very easy to write to a wrong device and lose data. There is no guarantee the device named /dev/sdx earlier is /dev/sdx now (that's why I used sdy in the examples). Study the output of lsblk and review your command twice before you run it. Get a rubber duck and explain to it why you're using e.g. /dev/sdc and not /dev/sda.
  • If /dev/sdy doesn't exist and you happen to write to it anyway then you will create a regular file that will take space in the filesystem.
  • Writing the image may not be enough for the current OS to recognize the restored partitions and to create /dev/sdy1, /dev/sdy2 etc. If you need to access them right away then use partprobe. Rebooting to the same or another OS (including the restored OS) will set things right without the need for calling partprobe explicitly.

I understand you're going to restore the image to the very same USB drive. If so, then the below remarks don't apply. In general though these are some potential problems:

  • A smaller device may be too small to hold all the partitions. If there's GPT then the secondary (backup) GPT will not fit in.
  • A larger device will be able to hold all the partitions, but if there's GPT then the secondary GPT will be written in the wrong place. It will keep its offset from the start while it should be placed at the very end. Programs like gdisk are able to fix this.
  • A device with different logical sector size will make the partition table not match the actual layout of your data. Compare this answer of mine.
1
  • Thank you! I figured linux would have a plethora of solutions to this issue, I just don't have access to it until tonight so I was hoping maybe there was some solution in Windows, but this works perfect as well. I'll just have to muster up a little patience. – Kaiziak Jun 3 '20 at 19:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.