|
Key
This line was removed.
This word was removed. This word was added.
This line was added.
|
Changes (15)
View Page History
...
h3. What is a UUID and what is it used for? h3. 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: !UUID 4.png|border=1!
!UUID 4.png|border=1!
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.
...h4. 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: !UUID 5.png|border=1!
!UUID 5.png|border=1!
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.
h4. ls \-l /dev/disk/by-uuid
h4. 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. !UUID 6.png|border=1!
!UUID 6.png|border=1!
As you can see, the *lvm* setup displays as well as the UUID for */boot* partition which is not associated with the LVM.
...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.
h4. 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. !UUID 7.png|border=1!
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.
h4. 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: !UUID 8.png|border=1!
!UUID 8.png|border=1!
2. Next, generate a UUID by using the command *uuidgen*. !UUID 9.png|border=1!
!UUID 9.png|border=1!
3. Use *tune2fs* to change the UUID of the selected partition. In this case, we changed the UUID of */dev/sdc*. !UUID 10.png|border=1!
!UUID 10.png|border=1!