device mapper, incosistent device numbers

[mike2307]

Hi there,

I'm experiencing some troubles with one of the listed items above:

Volume-level backup job relies on a device name under the /dev directory and requires volumes to have their corresponding device names under the /dev directory staying persistent (e.g. /dev/md-127, /dev/dm-1). Otherwise the job will back up the wrong volume.

In my case, I have 2 LUKS-encrypted partitions which appear as /dev/dm-0 and /dev/dm-1 and further with some named entries in /dev/mapper/*.
The problem is, that the numbering of /dev/dm-x is NOT consistent (at least in my case).

I'm running Fedora 30 and all my encrypted partitions are listed inside /etc/crypttab. This is translated to some systemd unit files when booting.
Those systemd unit files are allowed to be executed in parallel. This causes the /dev/dm-x numbering to be kind of random.

As a consequence, the veeam backup agent performs a full backup of the affected partitions every time those numbers flip (my backup targets the entire machine).
Long story short: Is there any workaround to avoid this (e.g. enforcing the enumeration of /dev/dm-x)?

Thanks a lot in advance.

Kind regards,
Michael

[PTide]

Hi,

From the top of my head - you can use mountpoints instead of devices. I assume that those devices contain some valuable data and hence are mounted to some constant mountpoints?

Thanks!

[mike2307]

Unfortunately that didn't change the behaviour.
I changed from an entire machine backup to a volume level backup (and selecting all mount points).

My trouble is the following:
I have 2 encrypted volumes, which are named enc-home and enc-var within /etc/crypttab.
Inside /etc/fstab those partitions are only referenced by their given name (enc-home to /home, enc-var to /var).

Sometimes after booting, the content of /dev/mapper/ is

Code: Select all

enc-home -> ../dm-0
enc-var -> ../dm-1

Sometimes after booting, the content of /dev/mapper/ is

Code: Select all

enc-home -> ../dm-1
enc-var -> ../dm-0

I guess that veeam "thinks" that devices have completely changed (which they haven't in practice) and performs a full backup of those partitions.

I guess I either need

• a way to enforce the ordering of /dev/dm-x OR
  a change in veeam (or it's config) to treat this situation in a better way

Kind regards,
Michael

[PTide]

Ok, noted. The best option IMO would be to enforce the following behaviour of the product:

If a mountpoint is chosen for backup, use the mountpoint as the primary identifier and thus assume that it is always the same device, no matter what dm device it is pointing to, and proceed with incrementals.

Regarding the way to enforce the ordering - I need to do some research as I can't come up with a solution right now.

Thanks!