Chris's Wiki :: blog/solaris/ZFSBookmarksWhatFor Commentshttps://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSBookmarksWhatFor?atomcommentsDWiki2019-07-10T22:14:39ZRecent comments in Chris's Wiki :: blog/solaris/ZFSBookmarksWhatFor.By Mark Costlow <cheeks@swcp.com> on /blog/solaris/ZFSBookmarksWhatFortag:CSpace:blog/solaris/ZFSBookmarksWhatFor:d0f653d4f5a356c8fea3800fefdbc57a3b156f50Mark Costlow <cheeks@swcp.com><div class="wikitext"><p>After reading about bookmarks (a few times) I'm still not 100% clear on why they don't consume space the way a snapshot would. (Like how is the delta from the bookmark to a newer snapshot accurate if the bookmark hasn't preserved the state of the volume the way a snapshot would?) I'll keep reading on that.</p>
<p>The reason I'm commenting is to say I've found another use case for bookmarks. I want to do periodic backups using ZFS replication, as in
your example. But the source filesystem is itself the target of other ZFS replications. In other words, client machine backs up to zfs1, and zfs1 periodically backs up to an encrypted offsite disk, with each of these backups executed via "zfs send/recv".</p>
<p>The problem is the act of creating a snapshot for the offsite copy causes the next replication from a client machine to fail because the most recent snapshot on the destination does not match the incremental source.</p>
<p>My answer (works in testing, working on deployment) is: after send/recv of the "offsite" snapshot to the offsite disk, make a bookmark from the offsite snapshot, then delete the offsite snapshot. When this disk rotates back in a few weeks later, I still have that bookmark on zfs1 that I can use as the origin to send a new incremental. In the meantime, the existence of that bookmark does NOT prevent further sends TO zfs1.</p>
<p>The space savings will be an extra bonus ... with several offsite disks in a rotation, the bookmarks may need to live for weeks but they won't prevent space from being reclaimed if/when newer snapshots are deleted.</p>
</div>2019-07-10T22:14:39ZBy Michael Nino on /blog/solaris/ZFSBookmarksWhatFortag:CSpace:blog/solaris/ZFSBookmarksWhatFor:376b6d6a04ea5770e96259016a851e4d704af160Michael Nino<div class="wikitext"><p>We often snapshot Staging when we refresh data from Production, creating a Bookmark allows us to track our data refreshes w/o needed actually consuming the storage space in that environment that doesn't need it.</p>
</div>2017-06-30T18:49:18ZBy Chris Siebenmann on /blog/solaris/ZFSBookmarksWhatFortag:CSpace:blog/solaris/ZFSBookmarksWhatFor:b2addf959d57e81cad80a7354e25d09c1c7f0de1Chris Siebenmann<div class="wikitext"><p>I don't think bookmarks keep transaction groups alive, just record the
txg number and time. That's why they're only imperfect substitutes for
snapshots (which do keep the txg alive).</p>
</div>2017-02-23T17:42:26ZBy Adam Thurlow on /blog/solaris/ZFSBookmarksWhatFortag:CSpace:blog/solaris/ZFSBookmarksWhatFor:fb3f589b25645f7a4cd1563b69e1b48688042a2fAdam Thurlowhttp://thurloat.com<div class="wikitext"><p>Interesting feature, from my quick scans of the docs when I was looking into them -- I was under the impression that it had more to do marking (and keeping) transaction groups alive so they can be used as a point-in-time marker.</p>
</div>2017-02-23T17:26:56Z