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.
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/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
- It's very easy to write to a wrong device and lose data. There is no guarantee the device named
/dev/sdxnow (that's why I used
sdyin the examples). Study the output of
lsblkand review your command twice before you run it. Get a rubber duck and explain to it why you're using e.g.
/dev/sdydoesn'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/sdy2etc. 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
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
gdiskare 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.