What is a UUID and what is it used for?
A Universally Unique Identifier (UUID) is a 36-digit code that is used to identify or label something. For the purposes of this article, we will discuss UUIDs as they pertain to block level devices, which is what R1soft backs up. Older versions of Linux used labels to identify devices. You essentially assign each partition a label and the OS will mount the partition according to their location. Here is an example of what that looks like: 
This was the prevalent way to mount and identify devices before the use of UUIDs. However, there were some issues with this method. Let’s say you add another hard drive to the server in question and now it’s SDA. The drive that was SDA gets bumped to SDB. Since the label system uses partitions, now your partition scheme is faulty. This could lead to the system not starting and/or major system errors. It was not a very good system to use for mounting drives. Thus, a new system was devised. What if we gave every block device it’s on UUID? You can see an example of this below:
Since the partition will always have that UUID, no matter if the partition is moved from sdb to sdc it will still be mounted to the correct point. If you are wondering why you are only seeing this set up for boot, it’s because / is setup on a LVM. However, if you look at the output for lvdisplay below, you will see each LVM volume has its own UUID.
Pretty much every device in your system has a UUID that is unique to it and can be used to identify the device. Most Linux distros use UUID to mount filesystems by default.
How does R1Soft use UUID?
R1soft Server Backup Manager is used to back up block devices since we are backing up blocks and not actual files. This makes the UUID of block-level devices extremely useful for us, especially when it comes to tracking where the data for a block-level device goes on the OS. Let’s take a look at the following picture:
As you can see, a snapshot of boot has been started. I used the command blkid to see the UUIDs of all the block level devices on the system. As you can see the partition /boot and our snapshot for /boot have the exact same UUID. This is because the snapshot is a re-creation of that partition and is an exact copy of the /boot partition. We then send this information back to the Backup Manager and it keeps track of it. When you make a restore request, we use the UUIDs for the devices and well as LVM volumes to recreate the partition scheme of the OS.
How can I see the UUID for my devices?
Several commands can be used to view the UUID for your devices, but here are two of the most common methods:
BLKID
The command blkid can be used to view the UUID information of all block-level devices on the system. Note that this will not provide you with the UUID information for LVM partitions. An example of its use was provided above, but the following image also displays the command in action:
You’ll also see that R1soft supplies its own copy of blkid, but it generally returns the same information as the blkid provided by the OS.
ls -l /dev/disk/by-uuid
The second method is to do a ls on /dev/disk/by-uuid. This will again show you all the devices on your system that have a UUID.
As you can see, the lvm setup displays as well as the UUID for /boot partition which is not associated with the LVM.
What are some of the problems I can run into with UUIDs and R1Soft?
Generally speaking, you will not run into any issues using UUID if every device has a unique UUID. However, we have encountered some issues. Let’s take a look at the most common.
mount --a
Under no circumstances should you run a mount --a while a backup is occurring. As we saw earlier, when we create a snapshot of a block-level device, it is created with the same UUID device it is copying. 
When you run mount --a, you basically tell the OS to unmount all mounted partitions (including the snapshot) and remount them according to the information listed in fstab. However, Linux will not stop the two different partitions from being mounted to the same mount point. So since the snapshot and the actual partition have the same UUID, you risk the snapshot being mounted to the same mount point as the real partition. This leads to a scenario where the OS will start writing to the snapshot instead of the actual partition. This can potentially lead to loss of data, which is why we recommend that you wait for the Backup to run or mount the actual partition you need remounted individually.
Issue with LVM Snapshot cloning and duplicate UUID
Another common practice that can lead to issues is LVM cloning. Some software used to clone devices will also copy the UUID for the device. If you recall, we use UUID to identify each disk, which is essential during a BMR. Our Backup Software will fail the backup and warn you that it has detected a duplicate UUID. However, you just need to change the UUID for one of the devices. Here are instructions on how to do this:
1. Get the device path of the device you are trying to change. The blkid method is used in the image below:
2. Next, generate a UUID by using the command uuidgen.
3. Use tune2fs to change the UUID of the selected partition. In this case, we changed the UUID of /dev/sdc.
