Re: NFS exports of ZFS snapshots broken
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 18 Nov 2023 18:46:25 UTC
Rick Macklem <rick.macklem_at_gmail.com> wrote on Date: Sat, 18 Nov 2023 16:09:34 UTC: > . . . > I will try and get a test setup going here, which leads me to.. > how do I create a ZFS snapshot? (I do have a simple ZFS pool running > on a test machine, but I've never done a snapshot.) > . . . There is: "man zfs-snapshot" for "zfs snapshot" commands. I mention this in part because it references also using "zfs promote" to swap around the status of what is a snapshot vs. what is not. There is also the man page, accessible via: "man zfs-promote" . man zfs-snapshot also mentions destroying snapshots via "zfs destroy". The man pages have examples, such as: Example 1: Creating a ZFS Snapshot The following command creates a snapshot named yesterday. This snapshot is mounted on demand in the .zfs/snapshot directory at the root of the pool/home/bob file system. # zfs snapshot pool/home/bob@yesterday Example 3 involves all 3 operations (snapshot, promote, destroy) that I've referenced: Example 3: Promoting a ZFS Clone The following commands illustrate how to test out changes to a file system, and then replace the original file system with the changed one, using clones, clone promotion, and renaming: # zfs create pool/project/production populate /pool/project/production with data # zfs snapshot pool/project/production@today # zfs clone pool/project/production@today pool/project/beta make changes to /pool/project/beta and test them # zfs promote pool/project/beta # zfs rename pool/project/production pool/project/legacy # zfs rename pool/project/beta pool/project/production once the legacy version is no longer needed, it can be destroyed # zfs destroy pool/project/legacy The description of "zfs promote" is: DESCRIPTION The zfs promote command makes it possible to destroy the dataset that the clone was created from. The clone parent-child dependency relationship is reversed, so that the origin dataset becomes a clone of the specified dataset. The snapshot that was cloned, and any snapshots previous to this snapshot, are now owned by the promoted clone. The space they use moves from the origin dataset to the promoted clone, so enough space must be available to accommodate these snapshots. No new space is consumed by this operation, but the space accounting is adjusted. The promoted clone must not have any conflicting snapshot names of its own. The zfs rename subcommand can be used to rename any conflicting snapshots. === Mark Millard marklmi at yahoo.com