#186 dump 0.4-b52 does not find dumps in /etc/dumpdates, creates level 0

[Ernest Beinrohr]

Hi, I have noticed on some of our newer installs with dump b52 (others are b47) dump seems to ignore previous dumps and does a full dump. My workflow has not changed:

• create an LVM snapshot (same name always)
• mount to a random mktemp (/tmp/tmp.xxxx)
• dump that mount do remote ssh

this is what dump writes for b47 (fedora 39):

  Info: Mounting /dev/fedora_vncinstall/snap_backup_dump_rootfs to /mnt/tmp.XRHPeRhlWE
  Info: Running command: 'nice -n+10 /sbin/dump -m -h 0 -11 -z8 -u -f dumpkukana@backupserver:/BACKUP/kukana//kukana_2025-06-11_rootfs_l11.dmp /mnt/tmp.XRHPeRhlWE -L kukana_rootfs  '
  DUMP: Connection to backupserver established.
  DUMP: Date of this level 11 dump: Wed Jun 11 04:25:25 2025
  DUMP: Date of last level 10 dump: Tue Jun 10 04:21:20 2025
 DUMP: Dumping /dev/mapper/fedora_vncinstall-snap_backup_dump_rootfs (/mnt/tmp.XRHPeRhlWE) to /BACKUP/kukana//kukana_2025-06-11_rootfs_l11.dmp on host dumpkukana@backupserver
 DUMP: Label: kukana_rootfs

and this is the same machine with b52 (fedora 41 upgraded):

  Info: Mounting /dev/fedora_vncinstall/snap_backup_dump_rootfs to /mnt/tmp.BA1t79ZAfF
  Info: Running command: 'nice -n+10 /sbin/dump -m -h 0 -11 -z8 -u -f dumpkukana@backupserver:/BACKUP/kukana//kukana_2025-06-11_rootfs_l11.dmp /mnt/tmp.BA1t79ZAfF -L kukana_rootfs  '
Connection to backupserver established.
  DUMP: WARNING: There is no inferior level dump on this filesystem
  DUMP: WARNING: Assuming a level 0 dump by default
  DUMP: Date of this level 0 dump: Wed Jun 11 13:55:00 2025
  DUMP: Dumping /dev/mapper/fedora_vncinstall-snap_backup_dump_rootfs (/mnt/tmp.BA1t79ZAfF) to /BACKUP/kukana//kukana_2025-06-11_rootfs_l11.dmp on host dumpkukana@backupserver
  DUMP: Label: kukana_rootfs

[Tim Woodall]

Oh bother, this is because of a change that was supposed to make it easier (actually possible at all) where device nodes change.

TBH, It hadn't occured to me that someone would do this. If you're creating a snapshot, why do you mount it in order to dump it? You can use the device node directly (whether or not it's mounted)
nice -n+10 /sbin/dump -m -h 0 -11 -z8 -u -f dumpkukana@backupserver:/BACKUP/kukana//kukana_2025-06-11_rootfs_l11.dmp /dev/mapper/fedora_vncinstall-snap_backup_dump_rootfs -L kukana_rootfs

If you're mounting it in order to trigger a journal replay due to taking a snapshot of a live fs, then it would be better to run fsck instead - which will also ensure any other inconsistencies from the snapshot are fixed before dumping.

I don't think there's a way to make changing mountpoints (which wants the old way of writing the device node to dump dates) and changing device node (where you dump using UUID= or LABEL=) can both work.

I'll have a think about whether it makes sense to add an option to make your workflow work again for the next release but even if I do that it will still require an update to the command you use.

The next release is in progress but it's some weeks or even months before I'm likely to be ready to push it.

[Ernest Beinrohr]

Hi, I have since updated my workflow. I use a static mountpoint which seems to work OK.

[Tim Woodall]

Fixed in v0.4b53 --use-blockdev-for-dumpdates restores the old behaviour