On Wed, Feb 20, 2013 at 4:49 PM, Markus Grundmann <mar...@freebsduser.eu> wrote:
> Whenever I modify zfs pools or filesystems it's possible to destroy [on a
> bad day :-)] my data. A new
> property "protected=on|off" in the pool and/or filesystem can help the
> administrator for datalost
> (e.g. "zpool destroy tank" or "zfs destroy <tank/filesystem>" command will
> be rejected
> when "protected=on" property is set).
> It's anywhere here on this list their can discuss/forward this feature
> request? I hope you have
> understand my post ;-)
I like the idea and it is likely not very hard to implement. This is
very similar to how snapshot holds work.
# zpool upgrade -v | grep -i hold
18 Snapshot user holds
So long as you aren't using a really ancient zpool version, you could
use this feature to protect your file systems.
# zfs create a/b
# zfs snapshot a/b@snap
# zfs hold protectme a/b@snap
# zfs destroy a/b
cannot destroy 'a/b': filesystem has children
use '-r' to destroy the following datasets:
# zfs destroy -r a/b
cannot destroy 'a/b@snap': snapshot is busy
Of course, snapshots aren't free if you write to the file system. A
way around that is to create an empty file system within the one that
you are trying to protect.
# zfs create a/1
# zfs create a/1/hold
# zfs snapshot a/1/hold@hold
# zfs hold 'saveme!' a/1/hold@hold
# zfs holds a/1/hold@hold
NAME TAG TIMESTAMP
a/1/hold@hold saveme! Wed Feb 20 15:06:29 2013
# zfs destroy -r a/1
cannot destroy 'a/1/hold@hold': snapshot is busy
Extending the hold mechanism to filesystems and volumes would be quite nice.
zfs-discuss mailing list