Since they take up very little space, state-based or metadata snapshots are more prominent. A copy-on-write (COW) or redirect-on-write (ROW) snapshot is another name for a state-based snapshot.
The metadata or pointers about what the data looks like at a specific point-in-time (PIT) are copied by COW and ROW snapshots. That'd be a small amount of data to deplete capacity, and it happens almost instantly. Nonetheless, there are considerable technological disparities.
The storage must be provisioned for the entire volume of data being snapshotted, according to COW. Several manufacturers now use thin provisioning, so it's not as difficult as it sounds. Only after the data has been copied is the storage allocated.
Only when modifications to the data set are about to be made is the data duplicated. The COW snapshot replicates the data about to be altered to the reserved space, which keeps a copy of the data as it was for that PIT well before adjustments are made.
Since the data being altered must be replicated first before any modifications can be made, this is referred to as a twofold write performance penalty. When the data changes, COW potentially makes an absolute replica of the data for every snapshot, but only if the data alters. The frequency and magnitude of snapshots a storage admin will take and preserve is naturally governed by the actual replication of the data.
Since it writes every changes to the data independently from the PIT snapshot image and binds those together along with pointers, ROW doesn't really need any storage reservations. ROW snapshots are frequently — but not often — within the same disk, file system, LUN, virtual volume or virtual file system.
ROW is a little more challenging than COW since it necessitates a little more intelligence (clever algorithms) when stitching the data together on reads. As the number of ROW snapshots grows, the increased complexity typically adds marginal latency to reads.
Because ROW doesn't really make replicas of the data and consumes less storage space than COW, it allows for more frequent snapshots to be taken and stored for longer periods of time. However, because there are no physical replicas of the data, ROW snapshots can pose a severe data security risk.
If the initial data is corrupted, all subsequent snapshots will be corrupted as well. If altered data is corrupted, any subsequent snapshots will be corrupted as well. It's worth noting that this also pertains to COW snapshots before they're replicated.
This isn't the only problem with COW and ROW data security. Both produce crash-consistent data images, which means the snapshots appear to be exact data replicas at a PIT, as though the system had just been shut down. The snapshots aren't application-aware, which in itself is problematic when dealing with structured data (data that requires a database).
It's feasible to take a snapshot of an inconsistent database application. If the database application is in an inconsistent state, the database administrator (DBA) must put in manual work and time to restore it back to a consistent state, which is commonly accomplished via observing and interpreting forward. On rare occasions, the DBA is unable to rectify the problem.
