ZFS snapshot Folder Disappearing

[Tim Gustafson]

Hi,

I have a FreeBSD 9.0-RELEASE box that's running ZFS with zpool version
28.  I can't recall if this pool was upgraded from an earlier zpool
version, or if it was created natively as a zpool version 28; is there
any way to check that?

I use snapshots for nightly backups.  I went in today to test to see
if the snapshots were working correctly, and I got the following:

root at bsd-06: cd /tank/export/projects/www/.zfs/snapshot
/tank/export/projects/www/.zfs/snapshot: Not a directory.

I'm getting the same error when I try to cd into the snapshot folder
on any of my filesystems that have snapshots.

The zpool is healthy, reporting no errors, and was last scrubbed less
than a month ago with no errors being reported.  The server had been
up for 51 days.  This server does not currently have a cache drive
installed, nor am I using de-dupe anywhere.

Based on some Googling around that I did, I ran:

zdb -d tank | grep %

and came up empty-handed - no errors appear to be reported there.

I do create and delete snapshots on a regular basis, and I saw some
chatter that suggested that might be the culprit, but I don't know how
else to check for that.

I updated to 9.0-RELEASE-p4 and rebooted.  The machine did not shut
down properly, so I had to power-cycle it.  Upon rebooting all the
way, the snapshots came back, but I wonder if they'll disappear again
after the next round of snapshot creation and removal?

Before anyone asks: presently, it would be feasible to do a "zfs send"
to back this system up, and then rebuild the pool an then do a "zfs
receive" to restore it, but that will become problematic shortly.
This server has 135TB of disks, and will probably be about half full
some time during the next few months.  I do have a mirror server with
another 135TB of disks that I could use for that sort of
backup/restore procedure, but it will be located at the far end of a
1GB network connection shortly, living about 50 miles away in a remote
data closet, so backing up and restoring that much data will become
more or less impossible.

-- 

Tim Gustafson
tjg at soe.ucsc.edu
831-459-5354
Baskin Engineering, Room 313A