Veritas NetBackup™ Snapshot Client Administrator's Guide
- Introduction
- Snapshot Client features
- About snapshot basics
- Off-host backup overview
- Off-host backup methods
- Snapshot Client requirements
- Installation
- Policy configuration
- Selecting the snapshot method
- Configuration parameters for Snapshot Client
- About using alternate client backup
- Configuring alternate client backup
- Policy configuration tips
- About disabling snapshots
- FlashBackup configuration
- Instant Recovery configuration
- About Instant Recovery
- About sizing the cache for Instant Recovery copy-on-write snapshots
- About configuring VxVM
- About storage lifecycle policies for snapshots
- Network Attached Storage (NAS) snapshot configuration
- Configuration of software-based snapshot methods
- Support for Cluster Volume Manager Environments (CVM)
- Configuration of snapshot methods for disk arrays
- About the new disk array snapshot methods
- Disk array configuration tasks
- OS-specific configuration tasks
- About VSS configuration (Windows)
- About EMC CLARiiON arrays
- Configuring NetBackup to access the CLARiiON array
- Configuring a NetBackup policy for a CLARiiON array method
- About EMC Symmetrix arrays
- About configuration for EMC_TimeFinder_Mirror
- About configuration for EMC_TimeFinder_Clone
- About HP EVA arrays
- Verifying connectivity from clients to array using SSSU 5.0
- About IBM DS6000 and DS8000 arrays
- Configuring NetBackup to access the IBM DS6000 or DS8000 array
- About IBM DS4000 array
- About Hitachi SMS/WMS/AMS, USP/NSC, USP-V/VM
- Hitachi array software requirements
- About HP-XP arrays
- About array troubleshooting
- Notes on Media Server and Third-Party Copy methods
- Backup and restore procedures
- About restores from a FlashBackup backup
- Instant Recovery restore features
- About configurations for restore
- About restoring from a disk snapshot
- Troubleshooting
- Logging directories for UNIX platforms
- Logging folders for Windows platforms
- FlashBackup and status code 13
- Appendix A. Managing nbu_snap (Solaris)
- Appendix B. Overview of snapshot operations
- Appendix C. NetBackup integration with CloudPoint for snapshot managment
How copy-on-write works
A copy-on-write snapshot is a detailed account of data as it existed at a certain moment. Unlike a mirror, a copy-on-write is not a copy of the data, but a specialized account of it.
The copy-on-write process works as follows: when a snapshot is required, any unfinished transactions or changes to the source data are allowed to complete, but new changes are temporarily stalled. The source is momentarily idled (made quiescent). Once the copy-on-write is activated, new transactions or changes (writes) to the source data are allowed to take place. However, the copy-on-write process briefly intercepts or holds the first write request that is issued for any particular block of data. While it holds those requests, it copies to cache the blocks affected by those writes, and keeps a record of the cached blocks. In other words, it reads each source block that is about to change for the first time. Then it copies the block's current data to cache, and records the location and identity of the cached blocks. Then the intercepted writes are allowed to take place in the source blocks.
Figure: Copy-on-write process shows the copy-on-write process.
The following table lists the phases that have been depicted in the diagram:
Phase | Action |
---|---|
Phase 1 | Image of source data is frozen; copy-on-write is activated. |
Phase 2 | New write requests to s4, s7, s8 are held by copy-on-write process (see arrows). |
Phase 3 | Copy-on-write process writes contents of blocks s4, s7, and s8 to cache. These blocks write to cache only once, no matter how many times they change in the source during the snapshot. |
Phase 4 | Copy-on-write process keeps a record of the number of writes to cache. |
Phase 5 | Write requests are now allowed to take place. |
The immediate results of the copy-on-write are the following: a cached copy of the source blocks that were about to change (phase 3), and a record of where those cached blocks are stored (phase 4).
The copy-on-write does not produce a copy of the source. It creates cached copies of the blocks that have changed and a record of their location. The backup process refers to the source data or cached data as directed by the copy-on-write process.
Figure: Backing up a copy-on-write shows the process for backing up a copy-on-write snapshot.
The following table lists the phases that have been depicted in the diagram:
Phase | Action |
---|---|
Phase 1 | Backup reads source data from s0, s1, s2, s3 |
Phase 2 | At s4, copy-on-write tells backup to read c0 instead of s4 |
Phase 3 | Next, the backup reads s5 and s6 from the source. |
Phase 4 | At s7 and s8, copy-on-write tells backup to read c1, c2 instead of s7, s8. |
Phase 5 | Backup continues reading of the source or cache, as directed by copy-on-write. |
Phase 6 | When backup completes, backup data is identical to original source. |
As this diagram shows, an accurate backup image is obtained by combining the unchanged portions of the data with the cache. When a backup of the snapshot begins, the backup application copies the source data (phase 1) until it encounters a block that changed after the copy-on-write process started. The copy-on-write tells the backup to skip that changed block and read in its place the cached (original) copy (phase 2). The backup application continues copying source data (phase 3) until it comes to another changed block. Cache is read again (phase 4) as the copy-on-write process dictates. The backup, when finished, is an exact copy of the source as it existed the moment the copy-on-write was activated.