Original Message
From: ToddAndMargo
Sent: Sunday, May 15, 2016 04:16
To: scientific-linux-users@fnal.gov
Subject: Re: What is this xfadump error?
Original Message
From: ToddAndMargo
Sent: Saturday, May 14, 2016 20:37
To: scientific-linux-users@fnal.gov
Subject: What is this xfadump error?
Hi All,
$ rpm -qa \*xfsdump\*
xfsdump-3.1.4-1.el7.x86_64
What is the meaning of this xfsdump error. There is
no /dev/sda on this system at the moment.
# /usr/sbin/xfsdump -v verbose -M 1 -L 1 -l 0 -f
/lin-bak/2016-05-14_15-49-55_homeXfsDump /home
/usr/sbin/xfsdump: dumping non-directory files
WARNING: Your hard drive is failing
Device: /dev/sda [SAT], unable to open device
/usr/sbin/xfsdump: ending media file
/usr/sbin/xfsdump: media file size 453262590208 bytes
/usr/sbin/xfsdump: dump size (non-dir files) : 453181559704 bytes
/usr/sbin/xfsdump: dump complete: 5404 seconds elapsed
/usr/sbin/xfsdump: Dump Summary:
/usr/sbin/xfsdump: stream 0 /lin-bak/2016-05-14_15-49-55_homeXfsDump
OK (success)
/usr/sbin/xfsdump: Dump Status: SUCCESS
And it succeeded!
/home is on /dev/sdb3
/lin-bak is /dev/sdc1
Really!
# fdisk -l /dev/sda
fdisk: cannot open /dev/sda: No such file or directory
Any idea?
Many thanks,
-T
On 05/14/2016 09:58 PM, prmari...@gmail.com wrote:
Sounds like your hard drive or the controller are having issues.
By any chance is/var on sda. XFSdump keeps a catalog in /var/lib/xfs which is
used for incremental backups.
I know this because about 3 or 4 years ago I had to file a bug ticket with Red
Hat for RHEL 6 about improper selinux contexts on that directory.
Hi Rrmarino,
It is not an incremental dump. But .... It is two removable
backups in a row. Due to this bug
https://bugzilla.redhat.com/show_bug.cgi?id=1257018
The backup drive mounts on /dev/sda the first time,
gets removed and the second drive mounts on /dev/sdc.
This error occurred on the second drive.
Maybe it is using this catalog?
On 05/15/2016 08:01 AM, prmari...@gmail.com wrote:
It always uses the catalog, even though you are doing full dumps it updates the
catalog so you can do incremental in the future.
It also knows where the backups were stored and where to restore them by
default.
I think we have found the source of the error. Now we wait ...
https://bugzilla.redhat.com/show_bug.cgi?id=1336160
