Veritas NetBackup™ Vault™ Administrator's Guide
- About Vault
- About the Vault process
- Installing Vault
- About installing and configuring Vault on UNIX and Linux systems
- About installing and configuring Vault on Microsoft Windows systems
- Best Practices
- About preferred vaulting strategies
- About how to ensure that data is vaulted
- About not Vaulting more than necessary
- About preparing for efficient recovery
- About avoiding resource contention during duplication
- About two processes trying to use the same drive
- About load balancing
- About how to avoid sending duplicates over the network
- About increasing duplication throughput
- About organizing reports
- Configuring NetBackup for Vault
- About off-site volume pools
- About creating catalog backup schedules for Vault
- About setting master server properties for Vault
- Configuring Vault
- About Vault configuration
- About configuring Vault Management Properties
- General tab (Vault Management Properties)
- Alternate Media Server Names tab (Vault Management Properties)
- Retention Mappings tab (Vault Management Properties)
- Reports tab (Vault Management Properties)
- About creating a vault
- About creating profiles
- Configuring a profile
- Duplication tab
- Catalog backup tab (Profile dialog box)
- Eject tab (Profile dialog box)
- Reports tab (Profile dialog box)
- Vaulting and managing media
- About Vault sessions
- About monitoring a Vault session
- About the list of images to be vaulted
- About ejecting media
- About injecting media
- About using containers
- About vaulting media in containers
- About managing containers and media
- About vaulting additional volumes
- About using notify scripts
- Creating originals or copies concurrently
- About the continue or fail for concurrent copies
- About creating duplicate images concurrently
- About generating reports
- About consolidating reports
- Vault report types
- Reports for media going off site
- Reports for media coming on-site
- Inventory reports
- Administering Vault
- About administering access to Vault
- About NetBackup Vault session files
- Using the menu user interface
- Debug logs
- Appendix A. Recovering from disasters
- About disaster recovery
- Appendix B. Vault file and directory structure
About developing disaster recovery plans
Developing a disaster recovery plan usually begins with an impact analysis that identifies the functions an organization requires to operate and determines how long each function can be unavailable until it affects the organization to an unacceptable extent.
Understanding the effect of disaster helps you identify the objectives for the recovery plan.
The following are examples of the objectives that may be in a disaster recovery plan:
Ensure service to customers by making critical resources available.
Minimize economic loss.
Secure company assets.
Minimize decision making during the recovery process.
Reduce reliance on key individuals.
Ensure a safe and orderly recovery within predetermined time period.
Maintain a sense of security and organizational stability.
The priority you assign your objectives depends on the needs of your organization. By setting clear, prioritized objectives for your disaster recovery plan, you can reduce your organization's exposure to risks and ensure that your critical systems and networks are available during disruptions.
You can use the two following approaches to create disaster recovery plans:
A general plan that is used any time a disaster occurs. A general plan should be flexible and is often impact-driven rather than disaster driven (that is, based on the effect to your organization rather than the type of disaster). A general plan usually is based on assumptions that define the scope of each impact in the plan. A general plan is easy to maintain and convenient. However, because it may require that some decisions are made at the time of disaster (such as assessing the type of impact and determining the response), the beginning of recovery can be delayed.
Multiple smaller plans, each used for a specific disaster that your organization has determined is most likely to occur. For example, individual plans often are created for power outages, network outages, fires, floods, and other similar occurrences. Individual disaster-specific plans are easier to create than a general plan. It is often clear which plan should be used, so fewer decisions are required at the beginning of recovery, which can result in quicker recovery. However, which plan to use may not always be clear (for example, if a fire causes a power outage). And if a disaster occurs for which a plan does not exist, recovery may be slow to begin and difficult to achieve.
A disaster recovery plan should be easy to follow and not require interpretation. Do not include unnecessary detail. If the plan is implemented, it will be in a time of high stress and pressure to perform; therefore, the plan should be simple, specific, and well tested.
You should publicize your disaster recovery plan within your organization so that everyone knows about it, understands how it works, and understands the reasoning behind the decisions in the plan.