[zfs-discuss] How to get the actual ZFS dataset size & how to recover a ZFS dataset?

Nick Gilmour nickeforos at gmail.com
Wed Dec 28 07:40:55 EST 2016


Gregor thanks for the quick response.

I can try that but why I cannot see old txg's now? Is something wrong with
my current configuration?

I have already tested without the patch but it didn't work.

Nick

On Wed, Dec 28, 2016 at 1:32 PM, Gregor Kopka (@zfs-discuss) <
zfs-discuss at kopka.net> wrote:

> You shouldn't need a patch to import with -T.
> Get the latest Ubuntu 16 (64bit) live DVD, boot it, login as root and issue
>
> apt-add-repository universe
> apt update
> apt install --yes debootstrap gdisk zfs-initramfs
>
> After that you should have a ZFS stack ready to import the pool.
>
> Keep in mind to work on copies only (or *at least* with -o readonly=on),
> so you can retry in case things go south.
>
> Gregor
>
>
> Am 28.12.2016 um 13:06 schrieb Nick Gilmour via zfs-discuss:
>
> Hi all,
>
> following the instructions from here:
> http://www.c0t0d0s0.org/archives/7621-Back-in-time-or-zpool-import-T.html
>
> I was able to restore a pool with an older txg on a testing VM after I
> have built and compiled the patch mentioned before. So I was able to get
> data from a previously deleted dataset. This has worked great.
>
> Now I'm trying to do the same with my real pool. I don't want to mess up
> my current ZFS installation so I'm working on my server with an Ubuntu
> 14.04 Live. After building and installing ZFS I've encountered the error:
>
>> *zpool: error while loading shared libraries: ...*
>
> which went away after:
>
>> *$ sudo ldconfig*
>
> Everything seems to be OK and I'm able to import my pool except I cannot
> restore to a previous state.
> When I try to import with an older txg I get the error:
>
>> *cannot import 'pool': No such file or directory*
>
> Also
>
>> *# zdb pool*
>
> shows nothing.
>
> So my assumption is that zdb has no knowledge of the old txg's and that
> they are not stored in the pool itself which brings me to my question:
> Where are the txg's stored? How can I load old txg's?
>
> Thanks in advance.
> Nick
>
> On Fri, Dec 23, 2016 at 12:11 AM, Ray Pating <ray.pating at gmail.com> wrote:
>
>> One caveat of ZFS is that, for all its capabilities for ensuring the
>> integrity of its data, when a user issues a command they better be 110%
>> sure of it.
>>
>> Pools have been affected by:
>>
>> * Accidentally adding a striped vdev to an existing pool (due to user
>> error or insufficient understanding)
>> * Not understanding ashift and causing pool IOPS to grind to a halt.
>> *Destruction of critical datasets due to user error.
>>
>> This is why you really should be doubly sure when issuing commands like
>> zfs destroy, since this usually does hard-to-recover-from actions on a
>> pool. The assumption is that you know what you are doing and really want to
>> destroy the dataset, thus the lack of recovery options.
>>
>> On Dec 23, 2016 4:04 AM, "Gordan Bobic via zfs-discuss" <
>> zfs-discuss at list.zfsonlinux.org> wrote:
>>
>>> On 22/12/16 17:39, Nick Gilmour via zfs-discuss wrote:
>>>
>>>> Hi Gregor,
>>>>
>>>> thanks for your response!
>>>> The server is down. Making full block-level copies of the drives to work
>>>> on is almost impossible. I don't have so much free capacity all at one
>>>> place and I have a spent a lot of money to build the new server.
>>>>
>>>> Thanks for the link. I have already this and I've already tested on a VM
>>>> I've set up for this reason. But unfortunately it doesn't work and the
>>>> reason is, there is an open bug since 2014 preventing the rollback:
>>>> https://github.com/zfsonlinux/zfs/issues/2452
>>>>
>>>> The good news are there is a patch which I'm about to try soon. But Is
>>>> it really like this? ZFS has not recovery tools or recovery mechanisms?
>>>> There is no other way to recover my data? I find it hard to believe.
>>>>
>>>
>>> You have to consider that ZFS has built in recovery mechanisms for just
>>> about every reasonable failure scenario where data might still be
>>> meaningfully recoverable, and it deals with it as well as can be reasonably
>>> expected - except for user error. Unfortunately, there is no reasonable
>>> defence against the latter. :-(
>>>
>>> Gordan
>>> _______________________________________________
>>> zfs-discuss mailing list
>>> zfs-discuss at list.zfsonlinux.org
>>> http://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>>>
>>
>
>
> _______________________________________________
> zfs-discuss mailing listzfs-discuss at list.zfsonlinux.orghttp://list.zfsonlinux.org/cgi-bin/mailman/listinfo/zfs-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20161228/25a2eb5f/attachment.html>


More information about the zfs-discuss mailing list