[Top] [All Lists]

Re: XFS restore don't restore

To: Fugazzi99 <fugazzi99@xxxxxxxxx>
Subject: Re: XFS restore don't restore
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 07 Jan 2013 14:39:04 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <50EB2814.2090500@xxxxxxxxxxx>
References: <50EB2073.1040609@xxxxxxxxx> <50EB2814.2090500@xxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
On 1/7/13 1:55 PM, Eric Sandeen wrote:
> On 1/7/13 1:22 PM, Fugazzi99 wrote:
>> Hi everyone,
>> I think I hit a problem of xfsrestore again.
>> I had some problems with my HD so I had to change it, after that I tried to 
>> restore from the last dump of yesterday.
>> I made it with the last xfsrestore/dump 3.1.2 but when I try to restore it 
>> with xfsrestore 3.1.0 from sysrescuecd I got for the root filesystem:
>> xfsrestore: using file dump (drive_simple) strategy
>> xfsrestore: version 3.1.0 (dump format 3.0) - type ^C for status and control
>> xfsrestore: searching media for dump
>> xfsrestore: examining media file 0
>> xfsrestore: dump description:
>> xfsrestore: hostname: orione
>> xfsrestore: mount point: /
>> xfsrestore: volume: /dev/sda2
>> xfsrestore: session time: Thu Jan  6 13:01:53 2013
>> xfsrestore: level: 0
>> xfsrestore: session label: "root"
>> xfsrestore: media label: "root"
>> xfsrestore: file system id: 4af7e15f-17b4-4b4e-9c2a-f57ec2d43385
>> xfsrestore: session id: 8981d37f-4c20-4723-b3bb-75465b833ea5
>> xfsrestore: media id: 904ce393-451d-4dc5-ba3a-1ea9a4d28687
>> xfsrestore: searching media for directory dump
>> xfsrestore: reading directories
>> xfsrestore: 25530 directories and 356365 entries processed
>> xfsrestore: directory post-processing
>> xfsrestore: restoring non-directory files
>> xfsrestore: WARNING: bad file header checksum
>> xfsrestore: WARNING: unable to resync media file: some portion of dump will 
>> NOT be restored
> ok, that doesn't look too good
>> xfsrestore: restore complete: 4 seconds elapsed
>> xfsrestore: Restore Summary:
>> xfsrestore:   stream 0 /root/sdb/dump/old/backup/dump/root.dump OK (success)
>> xfsrestore: Restore Status: SUCCESS
>> It restored only the directory tree and nothing else, also for the home 
>> directory I got this messages and nothing got restored.
>> I had 6 backups on different drives but they were all made with the last 
>> dump 3.1.2 and so they are all unaccessible now.
>> Basically I'm a little fucked if I will not be able to restore one of them I 
>> have lost all.
>> Is it a know incompatibility with different restore versions or I'm lost?
> Shouldn't be incompatible, but just in case, maybe you can try restoring w/ 
> the same version as created the dump (to some spare directory, so you don't 
> overwrite anything?)

FWIW, I just tested xfsdump 3.1.0 from the git tree:

# ../xfsdump-3.1.0  -f dumpfile /mnt/test
/root/git/xfsdump/.libs/lt-xfsdump: using file dump (drive_simple) strategy
/root/git/xfsdump/.libs/lt-xfsdump: version 3.1.0 (dump format 3.0) - type ^C 
for status and control
/root/git/xfsdump/.libs/lt-xfsdump:   stream 0 /root/git/xfsdump/dumpfile OK 
/root/git/xfsdump/.libs/lt-xfsdump: Dump Status: SUCCESS

and xfsrestore 3.1.2 from the git tree as well:

# ./xfsrestore-3.1.2 -f dumpfile /mnt/test/restore/
/root/git/xfsdump/.libs/lt-xfsrestore: using file dump (drive_simple) strategy
/root/git/xfsdump/.libs/lt-xfsrestore: version 3.1.2 (dump format 3.0) - type 
^C for status and control
/root/git/xfsdump/.libs/lt-xfsrestore: restoring non-directory files
/root/git/xfsdump/.libs/lt-xfsrestore: restore complete: 5 seconds elapsed
/root/git/xfsdump/.libs/lt-xfsrestore: Restore Summary:
/root/git/xfsdump/.libs/lt-xfsrestore:   stream 0 /root/git/xfsdump/dumpfile OK 
/root/git/xfsdump/.libs/lt-xfsrestore: Restore Status: SUCCESS

so it all seems ok here ...

I did make some changes in between those versions, and at one point forgot to 
translate some unused bits IIRC:

commit b7af332bfdd208a563186f847dfce2eeb1e75669
Author: Eric Sandeen <sandeen@xxxxxxxxxx>
Date:   Thu Oct 18 23:02:05 2012 -0500

    xfsdump: fill in bs_forkoff
    Upstream, the structure containing bs_forkoff is actually zeroed
    prior to these functions, but when pulling the patch back to an
    older xfsdump, we got checksum errors due to an uninitialized
    bs_forkoff not matching in dump vs. restore.
    So even though forkoff won't be explicitly restored from
    a dump, do explicitly set it in these routines to keep checksums
    This fixes 'bad header checksum' errors in xfsrestore, which were
    introduced by commit 1e309da7.

so I don't know if maybe your distro version has those same issues,
maybe it's related...


<Prev in Thread] Current Thread [Next in Thread>