1. Application writes data 2. Snapshot is taken—snapshot manager saves metadata
3. When application modifies data, snapshot manager redirects new data to a different place on the disk (redirect on write)
4. Snapshot manager uses metadata to reconstruct original data
Primary storage
Application’s view of data
Original data Modified data
Metadata
Snapshot engine
There is another type of snapshot called a redirect on write. The initial process is the same. Application writes data, we quiesce, we flush, we take our snapshot. Our pointers are pointing back to the original data on the original primary volume. Now, because its called a redirect on write, when our application writes new data it can’t write it to this area so the write gets redirected to another disk location. Now, our applications view of data is no longer a contiguous file structure. We’re still using these pointers to read from the original volume. If something is write intensive this has less overhead. Because instead of writing it in the original location and having to move the original data, you just write it in a new location. But over time your long term read performance could get impacted because instead of being able to read ahead you’ve now got to read individual blocks so you finish up with a fragmented structure. Things like windows XP restore points used to use something similar to this. Most of the large vendors use Copy on Write.