Learn how to use ZFS clones to create writable copies of snapshots for safe testing and experimentation on Linux. This tutorial demonstrates creating snapshots, cloning them to isolated datasets, making changes safely, and verifying production data remains untouched.
What you’ll learn in this video:
- How to verify your ZFS pool status and configuration
- Setting up production data in ZFS datasets
- Creating snapshots for safe points in time
- Cloning snapshots to writable test environments
- Making experimental changes without risk
- Verifying production data remains untouched
- Cleaning up clones and snapshots
- Understanding ZFS copy-on-write technology
ZFS clones give you the freedom to experiment safely with your data. Unlike snapshots which are read-only, clones are writable copies that initially use almost no disk space thanks to copy-on-write technology. They’re perfect for testing system changes, trying new configurations, or providing isolated development environments without risking production data.
📝 Video Transcript
00:00 – Introduction
Welcome to linuxconfig.org. In this tutorial you’ll learn how to create ZFS clones for safe testing without affecting your production data. We’ll create a snapshot, clone it to a new dataset, make changes to the clone, and verify the original remains unchanged.
00:29 – Checking ZFS Configuration
Before we can continue we need to verify our ZFS pool configuration and check our existing datasets. First we’ll use zpool-version to confirm ZFS is installed and check the version. Then we’ll run zpool status to verify our pool named ZFS pool is online and see that it’s using disk SDB. Next we’ll use zfs list to view our datasets including the linuxconfig dataset mounted at slash zfspool slash linuxconfig. Keep in mind your output will be different depending on your specific ZFS setup, pool names, and disk configuration.
01:13 – Setting Up Production Environment
Let’s set up our production environment with some important files. We’ll navigate to slash zfspool slash linuxconfig and create two critical files. Important dot txt with production data and settings dot conf with configuration. Using ls dash lh we can see both files were created on November 6th at 8:33. The cat asterisk command displays our file contents, production data, and config file. These represent our production environment that we want to protect while testing changes. Before we make any modifications or experiments we need to preserve this exact state. This is where ZFS snapshots become essential for creating safe testing environments. Next we’ll create a snapshot of this production data.
02:10 – Creating a Snapshot
Now we’ll create a snapshot to preserve our production environment. We use sudo zfs snapshot followed by the dataset name zfspool slash linuxconfig at ep2 underscore snap. This instantly captures the current state of both files. Important dot txt and settings dot conf. The snapshot is now created and safely stored ready to be cloned for testing purposes.
02:39 – Creating a ZFS Clone
Here’s where ZFS clones shine creating a writable copy for testing. We use sudo zfs clone followed by the snapshot name zfspool slash linuxconfig at ep2 underscore snap and the new dataset name zfspool slash test clone. This creates an independent writable dataset based on our snapshot perfect for testing without affecting production data. The clone initially uses almost no disk space thanks to ZFS copy on write technology.
03:19 – Verifying the Clone
Let’s verify our clone was created successfully using ZFS list. We can now see three datasets the original zfspool slash linuxconfig at 24 kilobytes and our new clone zfspool slash test clone showing 0 bytes. The clone uses 0 bytes initially because it shares all blocks with the original snapshot. Notice the test clone is mounted at slash zfspool slash test clone, giving us a completely separate working directory for testing.
03:53 – Making Changes to the Clone
Now let’s make some experimental changes to our clone. We navigate to slash zfspool slash test clone and create a new file test dot txt with testing changes. Then we delete settings dot conf using rm to simulate testing a configuration change. Running ls dash lh shows we now have important dot txt from the original snapshot and our new test dot txt. The cat asterisk command confirms our clone contains production data and testing changes. Notice that settings dot conf is gone from the clone. These changes only affect the clone. Our original production data remains completely untouched.
04:40 – Verifying Original Data Intact
Let’s verify that our original production data is completely intact. We switch back to the production directory at slash zfspool slash linuxconfig. Running cat asterisk shows both production data and config file are still there. Using ls dash lh confirms both important dot txt and settings dot conf remain unchanged with their original timestamps from 8:33. Despite deleting settings dot conf and adding test dot txt in the clone, the original dataset is perfectly preserved. This demonstrates the power of ZFS clones. You can freely experiment and test changes in the clone without any risk to your production environment.
05:30 – Cleanup and Final Verification
Once testing is complete, we can clean up our clone and snapshot. We use sudo zfs destroy to remove the test clone dataset, then destroy the ep2 underscore snap snapshot. Running zfs list confirms we’re back to just our original linuxconfig dataset. Let’s verify our production data one final time by navigating to slash zfspool slash linuxconfig. The ls command shows both important dot txt and settings dot conf are still there. Using cat asterisk confirms our production files contain production data and config file. Exactly as they were before we started testing. ZFS clones give you the freedom to experiment safely, knowing your production data is always protected. Subscribe for more Linux tutorials and thanks for watching.