Re: xfsdump/xfsrestore confusion

[Mandy Kirkconnell <alkirkco@xxxxxxx>]

Nicolas Kowalski wrote:
> Hello.
>
> I am still confused about the behaviour of xfsdump and xfsrestore
> since we connected our SCSI tape drives directly on the fileserver,
> instead of using a remote sparc box.
>
> Last night, I started an incremental backup for the /export/home
> filesystem. There was a failure about xfsdq (problem of PATH corrected
> now), but I think this is not the point. Here is the log file:
>
>
> [begin logfile]
>
> Filesystem: /export/home
> /sbin/xfsdump: using scsi tape (drive_scsitape) strategy
> /sbin/xfsdump: version 2.2.12 (dump format 3.0) - Running single-threaded
> /sbin/xfsdump: saving user quota information for: /export/home
> sh: xfsdq: command not found
> /sbin/xfsdump: ERROR: xfsdq failed with exit status: 32512
> /sbin/xfsdump: ERROR: failed to save user quota information, continuing
> /sbin/xfsdump: level 2 incremental dump of gaspard:/export/home based on level 
> 1 dump begun Wed Jul 16 16:51:44 2003
> /sbin/xfsdump: dump date: Thu Jul 17 23:00:01 2003
> /sbin/xfsdump: session id: 4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0
> /sbin/xfsdump: session label: "/export/home"
> /sbin/xfsdump: ino map phase 1: skipping (no subtrees specified)
> /sbin/xfsdump: ino map phase 2: constructing initial dump list
> /sbin/xfsdump: ino map phase 3: pruning unneeded subtrees
> /sbin/xfsdump: status at 23:06:04: 363 seconds elapsed
> /sbin/xfsdump: ino map phase 4: estimating dump size
> /sbin/xfsdump: ino map phase 5: skipping (only one dump stream)
> /sbin/xfsdump: ino map construction complete
> /sbin/xfsdump: estimated dump size: 4793212544 bytes
> /sbin/xfsdump: preparing drive
> /sbin/xfsdump: WARNING: media may contain data. Overwrite option specified
> /sbin/xfsdump: creating dump session media file 0 (media 0, file 0)
> /sbin/xfsdump: dumping ino map
> /sbin/xfsdump: dumping directories
> /sbin/xfsdump: dumping non-directory files
> /sbin/xfsdump: status at 23:10:11: 2657/26281 files dumped, 21.7% complete, 610 
> seconds elapsed
> /sbin/xfsdump: status at 23:15:04: 15104/26281 files dumped, 57.9% complete, 
> 903 seconds elapsed
> /sbin/xfsdump: status at 23:20:23: 25823/26281 files dumped, 95.2% complete, 
> 1222 seconds elapsed
> /sbin/xfsdump: ending media file
> /sbin/xfsdump: media file size 4758437888 bytes
> /sbin/xfsdump: dumping session inventory
> /sbin/xfsdump: beginning inventory media file
> /sbin/xfsdump: media file 1 (media 0, file 1)
> /sbin/xfsdump: ending inventory media file
> /sbin/xfsdump: inventory media file size 2097152 bytes
> /sbin/xfsdump: writing stream terminator
> /sbin/xfsdump: beginning media stream terminator
> /sbin/xfsdump: media file 2 (media 0, file 2)
> /sbin/xfsdump: ending media stream terminator
> /sbin/xfsdump: media stream terminator size 1048576 bytes
> /sbin/xfsdump: dump size (non-dir files) : 4726257944 bytes
> /sbin/xfsdump: dump complete: 1261 seconds elapsed
> /sbin/xfsdump: Dump Status: SUCCESS
>
> [end logfile]
>
>
> This dump was appended to previous ones, at tape position 15.
> This morning, I tried to view the contents of this dump, so I did:
>
> gaspard:~# mt -f /dev/nst0 asf 15
> gaspard:~# /sbin/xfsrestore -t -f /dev/nst0 -F
> /sbin/xfsrestore: using scsi tape (drive_scsitape) strategy
> /sbin/xfsrestore: version 2.2.12 (dump format 3.0) - Running single-threaded
> /sbin/xfsrestore: searching media for dump
> /sbin/xfsrestore: preparing drive
> /sbin/xfsrestore: examining media file 1
> /sbin/xfsrestore: dump description: 
> /sbin/xfsrestore: hostname: gaspard
> /sbin/xfsrestore: mount point: /export/home
> /sbin/xfsrestore: volume: /dev/sdc1
> /sbin/xfsrestore: session time: Thu Jul 17 23:00:01 2003
> /sbin/xfsrestore: level: 2
> /sbin/xfsrestore: session label: "/export/home"
> /sbin/xfsrestore: media label: "dlt7000"
> /sbin/xfsrestore: file system id: ad42b81a-a874-4ee0-a37e-c76eecc24cde
> /sbin/xfsrestore: session id: 4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0
> /sbin/xfsrestore: media id: 0666aaec-d96a-4715-8c50-c0bfce24739b
> /sbin/xfsrestore: using online session inventory
> /sbin/xfsrestore: searching media for directory dump
> /sbin/xfsrestore: rewinding
> /sbin/xfsrestore: examining media file 0
> /sbin/xfsrestore: inventory session uuid (4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0) 
> does not match the media header's session uuid (e58f7869-908a-4ff0-b1c4-d02dbc02
> 1be2)
> /sbin/xfsrestore: table of contents display complete: 207 seconds elapsed
> /sbin/xfsrestore: Restore Status: SUCCESS
>
> So obiously, something is wrong. xfsdump told me the backup was
> successfull, but I am unable to restore any file from it.

Hi Nicolas,

I'm battling with this one right now.

It looks like there's a problem in the way xfsdump appends dumps to an 
existing dump session on tape.  I have only been experimenting with 
local tape drives so far (drive_scsitape strategy), but it sounds like 
you didn't see this problem when you were using remote tape drives 
(drive_minrmt strategy).  Interesting.. something to look into.

It looks like something strange is going on with the media files between 
the different dump sessions.  The numbering seems to get messed up and 
xfsrestore can't find the proper media file.  For example, my first dump 
session uses media files 0-2 and my second dump session uses media files 
2-4.  xfsresotore can restore the first session ok, but when it reaches 
the second session, it automatically advances to media file 3 (rather 
than 2).  The data at media file 3 is not the beginning of a dump, so 
xfsrestore advances to media file 4.  The data at media file 4 is also 
not the beginning of a dump session so xfsrestore advances to the end of 
data, then rewinds and starts searching forward from the beginning of 
the tape.  This process ends up looping forever (0.. 1.. 3.. 4.. rewind) 
printing the message you saw on evry mismatch (and never finding media 
file 2!!):

> /sbin/xfsrestore: inventory session uuid 
(4ace2eb4-7fe0-46d2-a38a-9c341e12b0d0)
> does not match the media header's session uuid 
(e58f7869-908a-4ff0-b1c4-d02dbc02
> 1be2)

I'm stepping through gdb now, I'll let you know when I have more info.

Mandy

--
Mandy Kirkconnell
SGI, Storage Software Engineer
alkirkco@xxxxxxx
651-683-3422