Re: [zfs-discuss] PSARC recover files?

2009-11-10 Thread BJ Quinn
Say I end up with a handful of unrecoverable bad blocks that just so happen to 
be referenced by ALL of my snapshots (in some file that's been around forever). 
 Say I don't care about the file or two in which the bad blocks exist.  Is 
there any way to purge those blocks from the pool (and all snapshots) without 
having to restore the whole pool from backup?
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-10 Thread Tim Cook
On Tue, Nov 10, 2009 at 2:40 PM, BJ Quinn bjqu...@seidal.com wrote:

 Say I end up with a handful of unrecoverable bad blocks that just so happen
 to be referenced by ALL of my snapshots (in some file that's been around
 forever).  Say I don't care about the file or two in which the bad blocks
 exist.  Is there any way to purge those blocks from the pool (and all
 snapshots) without having to restore the whole pool from backup?



No.  The whole point of a snapshot is to keep a consistent on-disk state
from a certain point in time.  I'm not entirely sure how you managed to
corrupt blocks that are part of an existing snapshot though, as they'd be
read-only.  The only way that should even be able to happen is if you took a
snapshot after the blocks were already corrupted.  Any new writes would be
allocated from new blocks.

--Tim
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-10 Thread A Darren Dunham
On Tue, Nov 10, 2009 at 03:04:24PM -0600, Tim Cook wrote:
 No.  The whole point of a snapshot is to keep a consistent on-disk state
 from a certain point in time.  I'm not entirely sure how you managed to
 corrupt blocks that are part of an existing snapshot though, as they'd be
 read-only.

Physical corruption of the media
Something outside of ZFS diddling bits on storage

 The only way that should even be able to happen is if you took a
 snapshot after the blocks were already corrupted.  Any new writes would be
 allocated from new blocks.

It can be corrupted while it sits on disk.  Since it's read-only, you
can't force it to allocate anything and clean itself up.

-- 
Darren
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-10 Thread Tim Cook
On Tue, Nov 10, 2009 at 3:19 PM, A Darren Dunham ddun...@taos.com wrote:

 On Tue, Nov 10, 2009 at 03:04:24PM -0600, Tim Cook wrote:
  No.  The whole point of a snapshot is to keep a consistent on-disk state
  from a certain point in time.  I'm not entirely sure how you managed to
  corrupt blocks that are part of an existing snapshot though, as they'd be
  read-only.

 Physical corruption of the media
 Something outside of ZFS diddling bits on storage

  The only way that should even be able to happen is if you took a
  snapshot after the blocks were already corrupted.  Any new writes would
 be
  allocated from new blocks.

 It can be corrupted while it sits on disk.  Since it's read-only, you
 can't force it to allocate anything and clean itself up.



You're telling me a scrub won't actively clean up corruption in snapshots?
That sounds absolutely absurd to me.

--Tim
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-10 Thread Nicolas Williams
On Tue, Nov 10, 2009 at 03:33:22PM -0600, Tim Cook wrote:
 You're telling me a scrub won't actively clean up corruption in snapshots?
 That sounds absolutely absurd to me.

Depends on how much redundancy you have in your pool.  If you have no
mirrors, no RAID-Z, and no ditto blocks for data, well, you have no
redundancy, and ZFS won't be able to recover affected files.

Nico
-- 
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-10 Thread BJ Quinn
I believe it was physical corruption of the media.  Strange thing is last time 
it happened to me it also managed to replicate the bad blocks over to my backup 
server replicated with SNDR...

And yes, it IS read only, and a scrub will NOT actively clean up corruption in 
snapshots.  It will DETECT corruption, but if it's unrecoverable, that's that.  
It's unrecoverable.  If there's not enough redundancy in the pool, I'm ok with 
the data not being recoverable.  But wouldn't there be a way to purge out the 
bad blocks if for example it was only in a single bad file out of millions of 
files, and I didn't care about the file in question?  I don't want to recover 
the file, I want to have a working version of my pool+snapshots minus the tiny 
bit that was obviously corrupt.

Barring another solution, I'd have to take the pool in question, delete the bad 
file, and delete ALL the snapshots.  Then restore the old snapshots from backup 
to another pool, and copy over the current data from the pool that had a 
problem over to the new pool.  I can get most of my snapshots back that way, 
with the best known current data sitting on top as the active data set.  
Problem is with hundreds of snapshots plus compression, zfs send/recv takes 
over 24 hours to restore a full backup like that to a new storage device.  Last 
time this happened to me, I just had to say goodbye to all my snapshots and 
deal with it, all over a couple of kilobytes of temp files.
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


[zfs-discuss] PSARC recover files?

2009-11-09 Thread Orvar Korvar
This new PSARC putback that allows to rollback to an earlier valid uber block 
is good.

This immediately raises a question: could we use this PSARC functionality to 
recover deleted files? Or some variation? I dont need that functionality now, 
but I am just curious...
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-09 Thread Rob Logan


frequent snapshots offer outstanding oops protection.

Rob
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-09 Thread Ellis, Mike
Maybe to create snapshots after the fact as a part of some larger disaster 
recovery effort.
(What did my pool/file-system look like at 10am?... Say 30-minutes before the 
database barffed on itself...)

With some enhancements might this functionality be extendable into a poor 
man's CDP offering that won't protect against (non-redundant) hardware 
failures, but can provide some relieve in App/Human creativity.

Seems like one of those things you never really need... Until you have to that 
one time, at which point nothing else will do.

One would think that using zdb and friends it might be possible to walk the 
chain of tx-logs backwards and each good/whole one could be a valid 
recover/reset-point.

--

This raises a more fundamental question that perhaps someone can comment on. 
Does ZFS's COW follow a fairly strict last released-block, last overwritten 
model (keeping a maximum buffer of in tact data), or do previously used 
blocks get overwritten largely based on block/physical location, 
fragmentation/best-fit, etc?). In cases of blank disks/LUNs, does for instance 
a 1TB drive get completely COW-ed onto its blank-space, or does zfs re-use 
previously used (and freed) space before burning through then entire disk-space?

Thanks,

 -- MikeE


-Original Message-
From: zfs-discuss-boun...@opensolaris.org 
[mailto:zfs-discuss-boun...@opensolaris.org] On Behalf Of Orvar Korvar
Sent: Monday, November 09, 2009 8:36 AM
To: zfs-discuss@opensolaris.org
Subject: [zfs-discuss] PSARC recover files?

This new PSARC putback that allows to rollback to an earlier valid uber block 
is good.

This immediately raises a question: could we use this PSARC functionality to 
recover deleted files? Or some variation? I dont need that functionality now, 
but I am just curious...
-- 
This message posted from opensolaris.org
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-09 Thread Rob Logan


 Maybe to create snapshots after the fact

how does one quiesce a drive after the fact?
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss


Re: [zfs-discuss] PSARC recover files?

2009-11-09 Thread Bryan Allen
+--
| On 2009-11-09 12:18:04, Ellis, Mike wrote:
| 
| Maybe to create snapshots after the fact as a part of some larger disaster 
recovery effort.
| (What did my pool/file-system look like at 10am?... Say 30-minutes before the 
database barffed on itself...)
| 
| With some enhancements might this functionality be extendable into a poor 
man's CDP offering that won't protect against (non-redundant) hardware 
failures, but can provide some relieve in App/Human creativity.

Alternatively, you can write a cronjob/service that takes snapshots of your 
important
filesystems. I take hourly snaps of our all our homedirs, and five-minute
snaps of our database volumes (InnoDB and Postgres both recover adequately; I
have used these snaps to build recovery zones to pull accidentally deleted data
from before; good times).

Look at OpenSolaris' Time Slider service, although writing something that does
this is pretty trivial (we use a Perl program with YAML configs launched by
cron every minute). My one suggestion would be to ensure the automatically
taken snaps have a unique name (@auto, or whatever), so you can do bulk expiry
tomorrow or next week without worry.

Cheers.
-- 
bda
cyberpunk is dead. long live cyberpunk.
___
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss