[zfs-discuss] How to get the actual ZFS dataset size & how to recover a ZFS dataset?
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.
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.
> Am 28.12.2016 um 13:06 schrieb Nick Gilmour via zfs-discuss:
> Hi all,
> following the instructions from here:
> 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*
>> *# 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.
> 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:
>>>> 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. :-(
>>> zfs-discuss mailing list
>>> zfs-discuss at list.zfsonlinux.org
> 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...
More information about the zfs-discuss