As discussed earlier, snapshots are not free. There is always a trade-off between cluster resource consumption (CPU, memory, disk), the potential for data fragmentation, and the benefit of increased data availability, protection, and recovery.
- Snapshots are created at the directory-level instead of the volume-level, thereby providing improved granularity.
- There is no requirement for reserved space for snapshots in OneFS. Snapshots can use as much or little of the available file system space as desirable.
- Quotas can be used to calculate a file and directory count that includes snapshot revisions, provided the quota is configured to include snaps in its accounting using the “--snaps=true” configuration option.
- The Lincount job will also include snapshot revisions of LINs in its count.
- Files with alternate data streams or resource forks are fully supported by SnapshotIQ.
- The SmartDedupe job will automatically ignore (and not deduplicate) file system snapshots.
- SnapshotDelete will only run if the cluster is in a fully available state (no drives or nodes are down).
- Snapshots of file clones, and shadow stores in general, are not allowed, since shadow stores have no hard links.
- Snapshot data will not be containerized by the OneFS Storage Efficiency for Healthcare PACS feature.
- A snapshot schedule cannot span multiple days: To generate snapshots from 5:00 PM Monday to 5:00 AM Tuesday, create one schedule that generates snapshots from 5:00 PM to 11:59 PM on Monday, and another schedule that generates snapshots from 12:00 AM to 5:00 AM on Tuesday.
- If a directory is moved, you cannot revert any snapshots of that directory which were taken prior to its move.
- In OneFS 8.2 and later, the “Archive files with snapshots” configuration setting has been removed from the CloudPools user interface.
- Attempting to take a SnapshotIQ read-only snapshot of a writable snapshot is not permitted and will fail.