ZFS: Difference between revisions
Created page with "This will be a quick overview on how to manage ZFS snapshots and volumes on a FreeBSD system. === A Few Assumptions === Assume that we have a simple volume named storage. '..." |
No edit summary |
||
| Line 1: | Line 1: | ||
This will be a quick overview on how to manage ZFS snapshots and volumes on a FreeBSD system. | This will be a quick overview on how to manage ZFS snapshots and volumes on a FreeBSD 9.0 system, but it should apply to Solaris as well. | ||
=== A Few Assumptions === | === A Few Assumptions === | ||
| Line 10: | Line 10: | ||
=== ZFS Snapshot === | === ZFS Snapshot === | ||
A ZFS snapshot is a read-only copy of the file system. It will not consume additional space when created. It will however grow in size when data gets modified. Snapshot contents can be accessed through a special .zfs/snapshot directory | A ZFS snapshot is a read-only copy of the file system. It can be listed using the <code>'''zfs list -t snapshot'''</code> command. | ||
'''# zfs list -t snapshot''' | |||
NAME USED AVAIL REFER MOUNTPOINT | |||
storage@20120820 31.4G - 3.21T - | |||
storage@20120924 134G - 4.15T - | |||
storage@20121028 36.2G - 4.26T - | |||
storage@20121201 33.2M - 4.55T - | |||
To create a new snapshot, run <code>'''zfs snapshot storage@today'''</code>. Note that this will not consume additional space when created. It will however grow in size when data gets modified. | |||
'''# zfs list -t snapshot''' | |||
NAME USED AVAIL REFER MOUNTPOINT | |||
storage@20120820 31.4G - 3.21T - | |||
storage@20120924 134G - 4.15T - | |||
storage@20121028 36.2G - 4.26T - | |||
storage@20121201 33.2M - 4.55T - | |||
storage@today '''0''' - 4.58T - | |||
Snapshot contents can be accessed through a special <code>.zfs/snapshot/</code> directory. Each snapshot will contain a read-only copy of the data that existed when the snapshot was taken. | |||
'''# ls /storage/.zfs/snapshot/''' | |||
20120820/ 20120924/ 20121028/ 20121201/ today/ | |||
To roll back to a specific snapshot, run <code>'''zfs rollback storage@yesterday'''</code>. This will restore your volume to the snapshot state. | |||
'''# zfs rollback storage@yesterday''' | |||
To delete a specific snapshot, run <code>'''zfs destroy storage@today'''</code>. Note that this will not work if other volumes depend on it. eg: If you cloned it as another volume. | |||
'''# zfs destroy storage@today''' | |||
=== Data Integrity === | |||
One of the strengths of ZFS its resiliency thanks to its transactional file system. The only way data stored on a ZFS volume to be in an inconsistent state is through hardware failure or some sort of fault with the ZFS implementation. Similar to a <code>fsck</code> on ext file systems, a ZFS scrub provides a way to perform filesystem checking. To initiate a scrub, run: | |||
'''# zpool scrub storage''' | |||
Once the scrub process is underway, you can view its status by running: | |||
'''# zpool status storage''' | |||
pool: storage | |||
state: ONLINE | |||
scan: scrub in progress since Mon Dec 3 23:54:53 2012 | |||
18.3G scanned out of 6.05T at 211M/s, 8h20m to go | |||
0 repaired, 0.30% done | |||
config: | |||
NAME STATE READ WRITE CKSUM | |||
storage ONLINE 0 0 0 | |||
raidz1-0 ONLINE 0 0 0 | |||
gpt/disk00 ONLINE 0 0 0 | |||
gpt/disk01 ONLINE 0 0 0 | |||
gpt/disk02 ONLINE 0 0 0 | |||
gpt/disk03 ONLINE 0 0 0 | |||
gpt/disk04 ONLINE 0 0 0 | |||
errors: No known data errors | |||
To stop a scrub process, run: | |||
'''# zpool scrub -s storage''' | |||
Revision as of 06:57, 4 December 2012
This will be a quick overview on how to manage ZFS snapshots and volumes on a FreeBSD 9.0 system, but it should apply to Solaris as well.
A Few Assumptions
Assume that we have a simple volume named storage.
# zfs list NAME USED AVAIL REFER MOUNTPOINT storage 4.81T 2.32T 4.55T /storage
ZFS Snapshot
A ZFS snapshot is a read-only copy of the file system. It can be listed using the zfs list -t snapshot command.
# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT storage@20120820 31.4G - 3.21T - storage@20120924 134G - 4.15T - storage@20121028 36.2G - 4.26T - storage@20121201 33.2M - 4.55T -
To create a new snapshot, run zfs snapshot storage@today. Note that this will not consume additional space when created. It will however grow in size when data gets modified.
# zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT storage@20120820 31.4G - 3.21T - storage@20120924 134G - 4.15T - storage@20121028 36.2G - 4.26T - storage@20121201 33.2M - 4.55T - storage@today 0 - 4.58T -
Snapshot contents can be accessed through a special .zfs/snapshot/ directory. Each snapshot will contain a read-only copy of the data that existed when the snapshot was taken.
# ls /storage/.zfs/snapshot/ 20120820/ 20120924/ 20121028/ 20121201/ today/
To roll back to a specific snapshot, run zfs rollback storage@yesterday. This will restore your volume to the snapshot state.
# zfs rollback storage@yesterday
To delete a specific snapshot, run zfs destroy storage@today. Note that this will not work if other volumes depend on it. eg: If you cloned it as another volume.
# zfs destroy storage@today
Data Integrity
One of the strengths of ZFS its resiliency thanks to its transactional file system. The only way data stored on a ZFS volume to be in an inconsistent state is through hardware failure or some sort of fault with the ZFS implementation. Similar to a fsck on ext file systems, a ZFS scrub provides a way to perform filesystem checking. To initiate a scrub, run:
# zpool scrub storage
Once the scrub process is underway, you can view its status by running:
# zpool status storage
pool: storage
state: ONLINE
scan: scrub in progress since Mon Dec 3 23:54:53 2012
18.3G scanned out of 6.05T at 211M/s, 8h20m to go
0 repaired, 0.30% done
config:
NAME STATE READ WRITE CKSUM
storage ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
gpt/disk00 ONLINE 0 0 0
gpt/disk01 ONLINE 0 0 0
gpt/disk02 ONLINE 0 0 0
gpt/disk03 ONLINE 0 0 0
gpt/disk04 ONLINE 0 0 0
errors: No known data errors
To stop a scrub process, run:
# zpool scrub -s storage