Bug#737564: dump should accomodate backups of media named by their UUID

[Andy Valencia]

Package: dump
Version: 0.4b44-1
Severity: normal

Dear Maintainer,

(Hi, Bdale! We have interacted in the past in the world of Forth.)

*** Please consider answering these questions, where appropriate ***

* What led up to the situation?

I have some disks brought over to a new server, where they will continue
to be used with their current contents.

* What exactly did you do (or not do) that was effective (or
ineffective)?

When time came for backups, I realized that /var/lib/dumpdates from their
old system would be needed in order to permit incremental backups. I
bought the file over, and converted the named devices in this file to their
/dev/disk/by-uuid/<id> path.

I then unmounted the disks, and attempted:

/sbin/dump -2u -f <backup-dev> /dev/disk/by-uuid/<id>

* What was the outcome of this action?

Instead of permitting me to back up from this increment, it noted that it
did not have previous state, and was going to do a level 0.

* What outcome did you expect instead?

If a disk is named by UUID device path, and that UUID device path is
correctly named in /var/lib/dumpdates, I would expect to be able to
do an incremental dump. Instead, I had to edit /var/lib/dumpdates
to reference the device by its /dev/sdXY pathname, mount the filesystem,
and then it permitted the incremental dump.

Note that this defect report is NOT trying to argue that the tool
should, in general, use UUID's to detect which disks are which. I
understand that this would be a very important change. But *if*
the UUID disk path is present in /var/lib/dumpdates *and* in the "dump"
command line (i.e., a UUID device path to an unmounted filesystem), I
think it would be correct to honor the dumpdates state and permit
an incremental dump.

*** End of the template - remove these lines ***


-- System Information:
Debian Release: 7.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: armhf (armv7l)

Kernel: Linux 3.4.75+ (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages dump depends on:
ii e2fslibs 1.42.5-1.1
ii libblkid1 2.20.1-5.3
ii libc6 2.13-38
ii libcomerr2 1.42.5-1.1
ii libgcc1 1:4.7.2-5
ii libreadline6 6.2+dfsg-0.1
ii libselinux1 2.1.9-5
ii libtinfo5 5.9-10
ii libuuid1 2.20.1-5.3
ii tar 1.26+dfsg-0.1

dump recommends no packages.

dump suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Elliott Mitchell]

For some time the Linux kernel hasn't guaranteed the order of block
devices. #737564 is a good solution to this issue.

(yeah, suddenly running into devices getting different designations due
to restart)


--
(\___(\___(\______ --=> 8-) EHM <=-- ______/)___/)___/)
\BS ( | ehem+...@m5p.com PGP 87145445 | ) /
\_CS\ | _____ -O #include <stddisclaimer.h> O- _____ | / _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

[Yusuf Ramadhan]

[Alexander Zangerl]

retitle 737564 dump: change dumpdates to support incrementals by UUID=blah
thanks

doing backups for uuid- and label-backed devices has worked since the switch
to libblkid (roughly around 2004), ie. "dump -0f someplace UUID=whatever" and
"dump -0f otherplace LABEL=tagyoureit" has and does work fine.

there are two uuid-related issues:

a) the documentation isn't uptodate, files-to-dump in dump.8 only
says mountpoint or device, and doesn't mention what
libblkid gained us, ie. it doesn't mention looking up devices by TOKEN=value.

that is easy to fix and i'll take care of that on the next upload.

b), which is the core of this bug report - dumpdates always only
saves the device name, hence doesn't find reordered devices.

i think the least messy way out is to rework the dumpdates stuff to
stop canonicalising the memorised device name, and instead park
whatever the user gave us for the device lookup. ie: if you dump -u /dev/sdy
then "/dev/sdy" will be saved, just as before, but if you
dump -u LABEL=foobardiddly then dumpdates will hold "LABEL=foobardiddly".

pro: 100% backwards compatible, and minimal amount of code change.
contra: you cannot mix incremental dumps of /dev/sdxyz with UUID=whatever
and expect dump to find one by the other. i think that's quite acceptable
a limitation, as long as it makes it into the documentation.

i'll be working on this Real Soon Now(tm).

regards
az


--
Alexander Zangerl + GPG Key 2FCCF66BB963BD5F + http://snafu.priv.at/
Never trust a computer you can't throw out the window. - S. Hunt