All of lore.kernel.org
 help / color / mirror / Atom feed
From: Una Thompson <una@unascribed.com>
To: Eric Sandeen <sandeen@sandeen.net>,
	"linux-xfs@vger.kernel.org" <linux-xfs@vger.kernel.org>
Subject: Re: Want help with messed-up dump
Date: Tue, 25 Jun 2019 19:04:36 +0000	[thread overview]
Message-ID: <E0REDMxgD0Z9MMDCXHS6GANHPUbjnE1afm9LzPBon36dr_WRyN0GNZsm9y1Yeagb2HoCqGq60LqFgmAscZvqSKF6mAVTUN8PluTThvD2s2c=@unascribed.com> (raw)
In-Reply-To: <df58093d-9b7f-a6e2-5859-bcab9e9617e1@sandeen.net>

On Tuesday, June 25, 2019 6:06 AM, Eric Sandeen wrote:

> On 6/25/19 12:00 AM, Una Thompson wrote:
>
> > Hi,
> > Years ago (around 2015, if I remember correctly), while shrinking a 4.3TiB XFS partition on a RAID5 array, I attempted to perform a dump/restore cycle and lost exactly half of my data. (I was shrinking the partition by a few MB to make room for LUKS metadata to encrypt the filesystem.)
> > The array had 4 disks (3 online, 1 spare) - I took two disks out, degrading the array, to make room for the dump. Rather than join the two disks into a JBOD, I used xfsdump's ability to write two files, as the disks were 3.7TiB each and the filesystem was nearly full. As said, this was years ago, I forget the exact invocation.
>
> Unfortunately xfsdump doesn't have a lot of experts anymore, but we can at least try.
>
> Just to be clear, you did something like
>
> xfsdump .... -f file1 -f file2 ?

Probably something like that; I can't be sure, this was years ago and the system that used to own this array that would have the .bash_history has since failed.

>
> and
>
> "The split is done in filesystem inode number (ino) order, at boundaries selected
> to equalize the size of each stream."
>
> and now you only have file2, and file1 is lost?

Yes. However, as far as I can tell, I successfully restored file1 at the time, and still have the restored files.

>
> > After restoring the dump to the new filesystem with the desired smaller size, I realized the filesystem was only half full. I looked around and a bunch of directories and files were missing. I tried xfsrestore again in various ways to try and get it to read both halves of the dump, but it'd always abort with an error when it finished with the first half.
> > I fully accept this was my fault and is user error, and I chalked it up as a learning experience at the time, and to avoid losing any more data, rejoined the disk with the first part of the dump to the array. However, now, I'm attempting to find some important files from 2011 or so that were on the array that were lost during this messed up dump/restore.
> > The spare was never used, and still has the second part of the dump on it; the part I believe didn't get restored correctly. The first part is now gone, after the RAID resync and LUKS format.
> > I've run photorec on the dump in an attempt to recover the files I'm looking for. I've found a few things that are familiar, but I'm mainly looking for a directory, not an archive, and photorec has been little help. Running xfsrestore on the orphaned half of the dump gives an error about a missing directory dump.
>
> sharing the exact error you get when you try would be helpful.

Knew I forgot something; sorry.

    xfsrestore: using file dump (drive_simple) strategy
    xfsrestore: version 3.1.6 (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: phi
    xfsrestore: mount point: /mnt/big
    xfsrestore: volume: /dev/md0
    xfsrestore: session time: Wed May 31 06:26:20 2017
    xfsrestore: level: 0
    xfsrestore: session label: ""
    xfsrestore: media label: ""
    xfsrestore: file system id: 19672483-ca53-4536-a1ff-eaf79740df38
    xfsrestore: session id: 8cbb75f6-8739-40ba-97fc-880780463595
    xfsrestore: media id: 9736ac42-07a4-4622-82c8-1a2bdf3e7f0b
    xfsrestore: searching media for directory dump
    xfsrestore: ERROR: no directory dump found
    xfsrestore: restore complete: 0 seconds elapsed
    xfsrestore: Restore Summary:
    xfsrestore:   stream 0 /mnt/foo/bigdump2 ERROR (operator error or resource exhaustion)
    xfsrestore: Restore Status: SUCCESS

Evidently, I did this in 2017. My time perception's pretty warped.

>
> -Eric
>
> > Is there anything at all I may be able to do to restore the data from this dump? I've tried everything I can think of and have been unsuccessful. I have a feeling by losing the first half of the dump I've made any recovery impossible, but I figured if anyone knew a way for me to climb out of this hole I've dug for myself, it'd be someone on the XFS list.
> > Thanks

  reply	other threads:[~2019-06-25 19:04 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-25  5:00 Want help with messed-up dump Una Thompson
2019-06-25 13:06 ` Eric Sandeen
2019-06-25 19:04   ` Una Thompson [this message]
2019-06-25 19:49     ` Eric Sandeen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='E0REDMxgD0Z9MMDCXHS6GANHPUbjnE1afm9LzPBon36dr_WRyN0GNZsm9y1Yeagb2HoCqGq60LqFgmAscZvqSKF6mAVTUN8PluTThvD2s2c=@unascribed.com' \
    --to=una@unascribed.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=sandeen@sandeen.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.