Вы находитесь на странице: 1из 46

EMC DL1500 and DL3000

with Veritas NetBackup


Best Practices Planning





































Abstract
This white paper contains a compilation of specific configuration and best practices information for the EMC


DL1500 and DL3000 with Veritas NetBackup.

July 2009




Copyright 2008, 2009 EMC Corporation. All rights reserved.
EMC believes the information in this publication is accurate as of its publication date. The information is
subject to change without notice.
THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATION
MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE
INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Use, copying, and distribution of any EMC software described in this publication requires an applicable
software license.
For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com
All other trademarks used herein are the property of their respective owners.
Part Number H5714.2
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 2



Table of Contents

Executive summary ............................................................................................ 5
Introduction......................................................................................................... 5
Audience ...................................................................................................................................... 5
Terminology ................................................................................................................................. 5
DL overview......................................................................................................... 7
Deduplication considerations............................................................................ 8
Backup policies ............................................................................................................................ 8
Change rate ................................................................................................................................. 8
Data types.................................................................................................................................... 8
Compression................................................................................................................................ 8
Encryption .................................................................................................................................... 9
Multiplexing.................................................................................................................................. 9
Filters ........................................................................................................................................... 9
Oracle RMAN ......................................................................................................................... 10
Configuring RMAN with NetBackup ....................................................................................... 10
Backing up the Oracle database............................................................................................ 14
Sizing ......................................................................................................................................... 15
Space management................................................................................................................... 15
Native format data.................................................................................................................. 16
Deduplicated data .................................................................................................................. 16
Phasing deduplication into the environment .............................................................................. 17
Network connectivity........................................................................................ 17
Best practices............................................................................................................................. 18
Veritas NetBackup concepts ........................................................................... 20
Licensing.................................................................................................................................... 20
Settings and considerations....................................................................................................... 20
Using the DL in a NAS environment................................................................ 21
General recommendations......................................................................................................... 21
Backup-to-disk configurations.................................................................................................... 21
Mounting NFS shares ................................................................................................................ 21
AIX 5.2.................................................................................................................................... 21
HP-UX 11i............................................................................................................................... 22
Linux....................................................................................................................................... 22
Solaris..................................................................................................................................... 23
Configuring CIFS shares............................................................................................................ 23
Performance tuning.................................................................................................................... 24
To improve performance on disk storage units and disk staging storage units..................... 24
Testing the source data to isolate bottlenecks....................................................................... 25
Using the DL in a SAN environment................................................................ 26
Media expiration......................................................................................................................... 26
DL SAN attach ........................................................................................................................... 26
Device discovery (persistent binding) .................................................................................... 26
Device drivers......................................................................................................................... 27
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 3



Scanning devices ................................................................................................................... 28
Configuring the backup server ................................................................................................... 28
Simultaneous backups............................................................................................................... 28
Single library with multiple hosts................................................................................................ 28
Virtual tape libraries ................................................................................................................... 29
Virtual tape cartridges................................................................................................................ 29
Performance tuning.................................................................................................................... 29
SIZE_DATA_BUFFERS......................................................................................................... 30
NUMBER_DATA_BUFFERS ................................................................................................. 30
NET_BUFFER_SZ ................................................................................................................. 30
Windows Server 2003 in a SAN environment............................................................................ 30
Copying to tape................................................................................................. 31
SAN attachment ......................................................................................................................... 31
Special considerations ........................................................................................................... 31
Backup application specific Path-to-Tape.................................................................................. 31
Site requirements for backup application specific PTT.......................................................... 32
Best practices......................................................................................................................... 32
To duplicate a virtual image ................................................................................................... 33
Restoring ................................................................................................................................ 33
Auto Archive............................................................................................................................... 33
Auto Archive site requirements .............................................................................................. 34
OpenStorage (OST) API support ..................................................................... 35
NetBackup optimized duplication............................................................................................... 36
General considerations when using optimized deduplication ................................................ 36
General considerations when using optimized deduplication with a DL replication license .. 36
Configuring NetBackup optimized duplication........................................................................ 37
Replicating deduplicated data ......................................................................... 38
Replication considerations......................................................................................................... 38
Seeding (pre-populating the target system)............................................................................... 40
Space management considerations .......................................................................................... 41
Recovery/Failback ..................................................................................................................... 41
Conclusion ........................................................................................................ 41
References ........................................................................................................ 41
Appendix: Using replication with NetBackup................................................. 42
DL setup..................................................................................................................................... 42
NetBackup setup........................................................................................................................ 42
Authentication setup .................................................................................................................. 42
Create the keys ...................................................................................................................... 42
Install the public key on the DL .............................................................................................. 43
Test the keys .......................................................................................................................... 43
NetBackup post-backup script example .................................................................................... 43
Recovery from a replicated NAS share ..................................................................................... 46

EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 4



Executive summary
The EMC

DL1500 and DL3000 appliances provide simple and reliable disk-based backup and recovery
systems with the added feature of deduplication. The DL provides leading-edge backup and restore
operations. It easily scales to meet your storage needs. There are many variables and parameters that can be
configured and implemented to optimize the DL for use with Veritas NetBackup. This white paper provides
specific configuration and best practices recommendations for the DL1500 and DL3000 appliances when
used with Veritas NetBackup in NAS and SAN environments.
Introduction
This white paper describes the DL appliance and the advantages it provides in the backup environment. It
covers its implementation and configuration in the NAS and SAN environments specific to its use with
Veritas NetBackup. It also includes a discussion of network connectivity, and a description of its copy to
tape, OpenStorage (OST) API support, and replication options. Recommended best practices are provided
throughout this document.
Audience
This white paper is intended for EMC customers, system engineers, and members of the EMC and partners
professional services community who are interested in configuration and best practices information when
using the DL appliances with Veritas NetBackup.
Terminology
Backup-to-disk (B2D) A backup solution where data is written to hard disk instead of tape.
Backup image A group of files or a file system that has been backed up on storage media.
Balance-rr mode A round-robin algorithm for transmitting and receiving data to and from peer
systems. This mode is also referred to as Mode 0 (see also Link Aggregation Control Protocol).
Block pool Deduplicated data stored on the DL back-end array.
Cartridge-level replication Process of verifying the contents of an individual cartridge in a source
VTL is present in a target VTL, the sending of the metadata description of the source cartridge, and the
rendering of that cartridge as a readable image on the target DL.
CIFS Protocol for a Windows-based network fileshare.
Data Protection Advisor (DPA) An EMC data protection management solution that provides
automatic and continuous data collection, conditional analysis that triggers alerts, and a single,
consistent interface for reporting.
Deduplication Process of detecting and identifying the redundant variable-length blocks (or data
segments) within a given set of data to eliminate redundancy.
Directory/file-level replication Process of verifying the contents of a directory or an individual file
in a NAS share on the source system is present in a NAS share on the target system, the sending of the
metadata description of the source directory or file, and the rendering of that directory/file as readable
data on the target DL.
Failback operation - The replicated NAS share or VTL is transferred from the target system to the
source system.
Immediate deduplication Process of deduplicating the backup datastream as it is ingested by the
DL appliance (see also scheduled deduplication).
Ingest Process of receiving backup data from the backup server.
Link Aggregation Control Protocol (LACP) Method for controlling the bundling of several
physical Ethernet ports together to form a single logical channel. LACP allows a network device to
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 5



negotiate an automatic bundling of links by sending LACP packets to the peer (a directly connected
device that also implements LACP). This mode is also referred to as Mode 4 (see also balance-rr
mode).
Locked State in which a target NAS share or VTL is unavailable for updating with the latest
replicated data. Any data replicated to a directory or file within a locked share or to a cartridge within a
locked VTL will be placed in an update queue on the target system (see also unlocked)
Logical Unit Number (LUN) Identifying number of a SCSI object that processes SCSI commands.
Media server System that writes data to an attached backup device.
Metadata description Sequence of unique blocks and pointers that represent the original data. The
receipt of this metadata description by the target system results in the generation of a recoverable
image.
Namespace replication Process of verifying that all data associated with the source is present at the
target followed by replication of the metadata description of the source.
NAS Network-attached storage.
Native format data Uncompressed backup data that has not been deduplicated.
NFS Protocol for cross-platform network fileshares.
Partial replication The recovery point representing a VTL or NAS share or a readable image
representing cartridge or a directory/file on the target system is missing data present in its source
equivalent.
Policy-based deduplication The choice of immediate, scheduled, or no deduplication.
Recovery operation - The replicated NAS share or VTL (recovery point) is made available for use on
the target DL system.
Recovery point A replicated NAS share or VTL on the target system whose metatdata description
has also been replicated resulting in an image that can be manually recovered on the target DL.
Remote replication Backup data residing on a DL is copied over a LAN or WAN to another DL for
disaster recovery protection.
Scheduled deduplication Deduplication of data occurs after the backup stream has been ingested by
the DL (see also immediate deduplication).
Shoeshining An interruption in the datastream to a physical tape drive that requires the tape to be
repositioned on the drives head in a manner that causes a stop-start or shoeshine motion of the tape
device. This behavior is due to an inadequate data flow to the tape drive and slows overall
performance.
Single instance store Byte-level delta technology used to identify duplicate files within a given set
of data so that only a single copy of each file is saved.
Source-based deduplication Deduplication of backup data occurs at the client before it is sent to the
primary storage system.
Sync ID Tag by which a source-target destination is identified in a DL replication configuration for
cartridge-level or directory/file-level namespace replication.
Target-based deduplication Deduplication of backup data occurs at the target storage system.
Truncation DL space management function that removes the oldest blocks of data from storage
having a deduplication equivalent when used capacity exceeds 70 percent.
Unlocked State in which a target NAS share or VTL is available for updating with the latest
replicated data. If a locked NAS share or VTL is unlocked, any directory/file or cartridge with queued
replication data will be updated at that time (see also locked).
Virtual tape library (VTL) Software emulation of a physical tape library system.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 6



DL overview
The DL1500 and DL3000 are stand-alone backup-to-disk (B2D) appliances offering a network-attached
storage (NAS) front end (IP) and an optional virtual tape library (VTL) front end (FC). Both DL
configurations include data deduplication to efficiently store and archive data written to the appliance.
These appliances can be configured to present an NFS share or CIFS share in a NAS personality, or a
virtual tape library to the backup server. When enabled, both NAS B2D and VTL functionality can be used
simultaneously. With policy-based deduplication, the data can be deduplicated as soon as the backup
stream is sent to the appliance or scheduled to occur when the backup window has closed.
With its data deduplication capability, the DL appliance:
Eliminates redundant data from backups to reduce storage, enabling longer onsite retention, and
reduced replication costs
Performs sub-file comparisons on variable length data blocks to capture small block inserts and
overstrikes in unstructured data
Provides policy-based deduplication that is customer-tunable to adjust to changing backup
environments and optimize backup performance
Understands backup software metadata to optimize the backup process
Includes built-in data compression that is additive to deduplication in the data reduction process

The DL appliances replication option leverages the deduplication capability of the DL, substantially
reducing the amount of backup data that needs to be migrated to a remote site. DL replication provides
rapid local and remote restore with the following benefits:
Supports replication between any combination of DL1500 and DL3000 appliances
Permits bi-directional replication between DL appliances
Replicates deduplicated NAS shares and/or virtual tape libraries to reduce bandwidth
Checks and validates each data block before replication so that only unique data blocks are sent to the
target DL to further reduce network traffic
Supports up to 10 (5 in DL version 1.2 and later) source DLs to one target DL
Maintains a common data deduplication repository at the target DL for maximum storage savings
Replicates entire VTLs or NAS shares or individual tape cartridges (for VTL) and files (for NAS
shares)
Automatically recovers replicated tape cartridges and files on the target system
Defers tape cartridge/file replication during a backup window when a scheduled deduplication is used
Provides detailed replication reporting
Provides optional 128-bit AES data encryption for replicated data

The DL appliances Path-to-Tape (PTT) option provides two means for copying virtual tapes to physical
tape:
Backup application-specific path-to-tape that maintains catalog consistency of all tape copies
Auto Archive for the export/import of virtual tape contents with physical tape under the control of the
DL Console Manager

The DL appliances OST API support option integrates the DL with Symantec NetBackup media servers.
The NetBackup policies control when backups and duplication operations occur while the DL manages
deduplication and replication. This option provides the following benefits:
Shared disks. Multiple NetBackup media servers can access the same disk volume concurrently.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 7



Load balancing and performance. NetBackup balances its backup jobs and storage usage by choosing
the least full disk volume and least used media server in the environment.
DL data deduplication and replication. Images backed up to the DL using OST are deduplicated and
can later replicate to another DL without requiring any user intervention.
NetBackup optimized duplication. NetBackup leverages the DLs ability to replicate deduplicated
images to efficiently duplicate an image from one DL to another.
Since NetBackup is managing the duplication of LSU data, multiple targets can be configured through
the Storage Lifecycle Policies in NetBackup with NetBackup aware of all copies.
Deduplication considerations
The ratio of the amount of storage space required to store the total number of backup images in a
conventional disk storage system to the storage capacity used in a deduplication system is referred to as the
deduplication ratio. There are many factors that affect deduplication ratios. Some key factors include:
Backup policies
Retaining data for longer periods of time improves the chance that common data will already exist in
storage, resulting in greater storage savings and better deduplication ratios.
Whether performing backups of similar data according to a daily full or weekly full/incremental model, the
amount of data storage required is essentially the same as only unique data is stored using either model.
Since the amount of data sent to the DL is substantially greater if doing daily full backups, the
deduplication ratio will be considerably higher for a policy of daily fulls rather than a policy of performing
a weekly full/incremental model. Of course, the amount of data moved by the client would be much, much
higher.
Change rate
When the first datastream is deduplicated, the number of unique blocks within it can vary widely depending
on the data type. The deduplication process may find little or no data redundancy to 50 percent or more
data redundancy.
When multiple backups of the same policy are written to the DL, however, storage savings often increase
significantly with each new save set as only those data blocks that are unique to each backup need to be
written to disk. In conventional business operations, this unique data may represent only 1-2 percent of the
data present in each additional backup set. The remainder of the backup consists of pointers to data already
present on the DL.
Data types
Backups of user data such as text documents, PowerPoint presentations, spreadsheets, some database types,
source code, and Exchange are known to contain redundant data and are good deduplication candidates.
Other data sources such as audio, video, and scanned images consist of unique data and are not good
deduplication candidates unless backed up multiple times.
Compression
Compression does not affect deduplication of files that do not change. However, compression can cause
even a small change in a file to ripple throughout the compressed file, greatly reducing the commonality
that can be found between current and prior versions, or similar but not identical documents on different
machines. As a result, software client-side compression prevents optimal deduplication from taking place
since data that is already compressed cannot be efficiently deduplicated once it reaches target storage.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 8



Compressing data prior to sending it to the DL will most likely result in negligible redundancy and poor
deduplication ratios. Data should be uncompressed when transmitted to the DL to increase the matches the
deduplication engine can find in the datastream. The DL, in addition to deduplication, hardware-
compresses the deduplicated data when writing to storage.
Encryption
Encryption does not affect deduplication of files that do not change between backups. However, encryption
will cause even a small change in a file to ripple throughout a file when it is encrypted, greatly reducing the
commonality that can be found between current and prior versions, or similar but not identical documents
on different machines. Changing the data zone encryption passphrase will also change the encrypted form
of every document, preventing deduplication from finding commonality between current and prior
versions. As a result, software client-side encryption prevents optimal deduplication from taking place
since data that is already encrypted cannot be efficiently deduplicated once it reaches target storage.
To achieve encryption of backup data, consider the use of an encryption appliance deployed between the
DL and the physical tape library.
If encryption is required without a physical encryption appliance, avoid changing the data zone passphrase
frequently, so that the current version of an unchanged file is more likely to be identical to the prior
version. If poor deduplication ratios are achieved, it may be appropriate to create a dedicated NAS share or
VTL with deduplication turned off, to receive those backups.
Multiplexing
EMC customers typically use multiplexing for many reasons:
To avoid shoeshining on a physical tape drive
To increase concurrency for a given number of devices
To reduce complexity and user management effort for a given level of concurrency
To shorten the backup window by writing save sets from multiple clients to a single drive
simultaneously
To reduce the load on the storage nodes and server
While shoeshining does not apply to a DL, the other reasons do.
Multiplexing interleaves backup streams, writing a little of backup stream 1, then a little of backup stream
2, and so on, so that none of the clients sending datastreams need to wait for the other clients to finish.
Unfortunately, this interleaving of datastreams has a significant impact on deduplication efficiency.
Multiplexed streams hinder the deduplication process from efficiently identifying blocks of common data
because of the additional header information added to the data. In order to realize the full benefit of
deduplication, EMC strongly recommends multiplexing be turned off when using the DL.
Filters
Backup applications typically apply a specific metadata wrapper to the header of the backup set before
sending it to the storage device. This wrapper contains identifying information about the application as well
as the backup, exclusive to the user data. Each backup application has its own unique metadata wrapper
format. Since the content of this metadata changes from backup to backup (but the format does not), tests
have shown that deduplicating the entire datastream has a negative impact on deduplication ratios if the
deduplication appliance does not recognize the metadata wrapper. Filtering out this metadata wrapper and
deduplicating only the user data in the datastream noticeably improves the deduplication ratio of the same
datastream.
The DL's deduplication process scans the datastream as it receives it, looking for the identifying strings
embedded in the header of each backup set. If it finds an identifier it recognizes, the deduplication process
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 9



invokes that filter which separates the metadata wrapper from the user data allowing for more efficient
deduplication.
Oracle RMAN
Oracle Recovery Manager (RMAN), a command-line and enterprise manager-based tool, is the Oracle-
preferred method for efficiently backing up and recovering an Oracle database. RMAN is designed to work
intimately with the server, providing block-level corruption detection during backup and restore. RMAN is
a native backup tool for Oracle and natively supports direct backup to disk. In order to backup to tape,
RMAN integrates with Oracle Secure Backup and with NetBackup. In either case, it should be noted that
RMAN backs up only filled Oracle database blocks while ignoring empty blocks.
Similar to a backup application, RMAN adds its own metadata wrapper while backing up an Oracle
database. Testing has shown that filtering out the RMAN metadata wrapper has a positive impact on the
deduplication ratio of an RMAN backup.
Note: Oracle RMAN also is able to multiplex images. Deduplication ratios are much lower, however, when
multiplexing is used. In order to achieve optimal deduplication, Oracle RMAN multiplexing must be
disabled. This can be achieved by setting the filesperset value to 1 and Allocate channel value
equivalent to the number of file sets to be backed up. Setting these two parameters in this manner will
ensure each channel gets one virtual tape drive (or one NAS share) and the resulting backup image is not
interleaved or multiplexed.
When RMAN is integrated with NetBackup, the RMAN data is encapsulated within the datastream. To
achieve optimal deduplication, it is necessary for the deduplication process to invoke both the NetBackup
filter as well as the RMAN filter. This filter composition is available in DL version 1.1 and later.
RMAN can also back up directly to a NAS share on the DL. Once the deduplication engine identifies the
stream as belonging to RMAN, it automatically applies the RMAN filter. This does not require any third-
party backup software. DL 1.1 includes the RMAN filter for Oracle version 10.2 with a disk block size of
8K (default). DL 1.2 and later include disk block sizes of 2K, 4K, 16K, and 32K in addition to 8K for the
RMAN filter.
Configuring RMAN with NetBackup
NetBackup for Oracle integrates the database backup and recovery capabilities of Oracle RMAN with the
backup and recovery management capabilities of NetBackup and its media manager and requires that the
Oracle extension license key be installed on the media manager.
The following steps walk through configuring NetBackup for Oracle RMAN backups.
1. Right-click on Policies in the left pane of the NetBackup Administration Console and click New.
2. Provide a unique name for the new policy and enable Use Backup Policy Configuration Wizard by
selecting the checkbox. Click OK.

Figure 1. Adding a new policy
3. Click Next and select Oracle as the Policy type.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 10



4. Add the client.
5. On the Backup Type screen, select the Automatic full backup checkbox.
6. Modify the following script for the host environment (ORACLE_HOME, ORACLE_SID,
TARGET_CONNECT_STR) and specify the script path to the NetBackup media server.
@REM ---------------------------------------------------------------------------
@REM hot_database_backup.cmd
@REM ---------------------------------------------------------------------------
@REM This script uses Recovery Manager to take a hot (inconsistent) database
@REM backup. A hot backup is inconsistent because portions of the database are
@REM being modified and written to the disk while the backup is progressing.
@REM You must run your database in ARCHIVELOG mode to make hot backups.
@REM
@REM NOTE information for running proxy backups has been included. These
@REM information sections begin with a comment line of PROXY
@REM ---------------------------------------------------------------------------

@setlocal ENABLEEXTENSIONS
@echo off
@set RMAN_LOG_FILE="%~dpn0.out"

@REM ---------------------------------------------------------------------------
@REM Replace below, with the actual Oracle home path.
@REM ---------------------------------------------------------------------------

@set ORACLE_HOME=c:\app\Administrator\product\11.1.0\db_1

@REM ---------------------------------------------------------------------------
@REM Replace below, with the Oracle SID.
@REM ---------------------------------------------------------------------------

@set ORACLE_SID=orcl

@REM ---------------------------------------------------------------------------
@REM Replace sys/manager, below, with the target connect string.
@REM ---------------------------------------------------------------------------

@set TARGET_CONNECT_STR=sys/oracle

@REM ---------------------------------------------------------------------------
@REM Set the Oracle Recovery Manager.
@REM ---------------------------------------------------------------------------

@set RMAN=%ORACLE_HOME%\bin\rman.exe

@for /F "tokens=1*" %%p in ('date /T') do @set DATE=%%p %%q
@for /F %%p in ('time /T') do @set DATE=%DATE% %%p

@echo ==== started on %DATE% ==== >> %RMAN_LOG_FILE%
@echo Script name: %0 >> %RMAN_LOG_FILE%

@set NLS_LANG=american
@set NLS_DATE_FORMAT=YYYY-MM-DD:hh24:mi:ss

@REM ---------------------------------------------------------------------------
@REM Print out environment variables set in this script.
@REM ---------------------------------------------------------------------------

@echo # >> %RMAN_LOG_FILE%
@echo RMAN : %RMAN% >> %RMAN_LOG_FILE%
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 11



@echo NLS_LANG : %NLS_LANG% >> %RMAN_LOG_FILE%
@echo ORACLE_HOME : %ORACLE_HOME% >> %RMAN_LOG_FILE%
@echo ORACLE_SID : %ORACLE_SID% >> %RMAN_LOG_FILE%
@echo NLS_DATE_FORMAT : %NLS_DATE_FORMAT% >> %RMAN_LOG_FILE%
@echo RMAN_LOG_FILE : %RMAN_LOG_FILE% >> %RMAN_LOG_FILE%

@REM ---------------------------------------------------------------------------
@REM PROXY
@REM For a PROXY backup, uncomment the line below.
@REM ---------------------------------------------------------------------------
@REM @echo NB_ORA_PC_STREAMS : %NB_ORA_PC_STREAMS% >> %RMAN_LOG_FILE%

@REM ---------------------------------------------------------------------------
@REM Print out environment variables set in bphdb.
@REM ---------------------------------------------------------------------------

@echo NB_ORA_SERV : %NB_ORA_SERV% >> %RMAN_LOG_FILE%
@echo NB_ORA_FULL : %NB_ORA_FULL% >> %RMAN_LOG_FILE%
@echo NB_ORA_INCR : %NB_ORA_INCR% >> %RMAN_LOG_FILE%
@echo NB_ORA_CINC : %NB_ORA_CINC% >> %RMAN_LOG_FILE%
@echo NB_ORA_CLASS : %NB_ORA_CLASS% >> %RMAN_LOG_FILE%

@REM ---------------------------------------------------------------------------
@REM We assume that the database is properly opened. If desired, this would
@REM be the place to verify that.
@REM ---------------------------------------------------------------------------

@REM ---------------------------------------------------------------------------
@REM If this script is executed from a NetBackup schedule, NetBackup
@REM sets an NB_ORA environment variable based on the schedule type.
@REM For example, when:
@REM schedule type is BACKUP_TYPE is
@REM ---------------- --------------
@REM Automatic Full INCREMENTAL LEVEL=0
@REM Automatic Differential Incremental INCREMENTAL LEVEL=1
@REM Automatic Cumulative Incremental INCREMENTAL LEVEL=1 CUMULATIVE
@REM
@REM For user initiated backups, BACKUP_TYPE defaults to incremental
@REM level 0 (Full). To change the default for a user initiated
@REM backup to incremental or incrementatl cumulative, uncomment
@REM one of the following two lines.
@REM @set BACKUP_TYPE="INCREMENTAL LEVEL=1"
@REM @set BACKUP_TYPE="INCREMENTAL LEVEL=1 CUMULATIVE"
@REM
@REM Note that we use incremental level 0 to specify full backups.
@REM That is because, although they are identical in content, only
@REM the incremental level 0 backup can have incremental backups of
@REM level > 0 applied to it.
@REM ---------------------------------------------------------------------------

@REM ---------------------------------------------------------------------------
@REM What kind of backup will we perform.
@REM ---------------------------------------------------------------------------

@if "%NB_ORA_FULL%" EQU "1" @set BACKUP_TYPE=INCREMENTAL Level=0
@if "%NB_ORA_INCR%" EQU "1" @set BACKUP_TYPE=INCREMENTAL Level=1
@if "%NB_ORA_CINC%" EQU "1" @set BACKUP_TYPE=INCREMENTAL Level=1 CUMULATIVE
@if NOT DEFINED BACKUP_TYPE @set BACKUP_TYPE=INCREMENTAL Level=0

@(
echo RUN {
echo ALLOCATE CHANNEL ch00 TYPE 'SBT_TAPE';
echo backup database;
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 12



echo RELEASE CHANNEL ch00;
echo }
) | %RMAN% target %TARGET_CONNECT_STR% nocatalog msglog '%RMAN_LOG_FILE%' append

@set ERRLEVEL=%ERRORLEVEL%

@if %ERRLEVEL% NEQ 0 @goto err

@set LOGMSG=ended successfully
@if "%STATUS_FILE%" EQU "" goto end
@echo 0 > "%STATUS_FILE%"
@goto end

:err
@set LOGMSG=ended in error
@if "%STATUS_FILE%" EQU "" @goto end
@echo 1 > "%STATUS_FILE%"

:end

@REM ---------------------------------------------------------------------------
@REM Log the completion of this script.
@REM ---------------------------------------------------------------------------

@for /F "tokens=1*" %%p in ('date /T') do @set DATE=%%p %%q
@for /F %%p in ('time /T') do @set DATE=%DATE% %%p

@echo # >> %RMAN_LOG_FILE%
@echo %==== %LOGMSG% on %DATE% ==== >> %RMAN_LOG_FILE%
@endlocal
@REM End of Main Program -----------------------------------------------------

7. On the remaining policy setup screens, click Next to accept the defaults.
8. Double-click on the policy and set the Policy Storage Unit and Policy Volume Pool attributes. These
values are VTL specific.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 13




Figure 2. Set policy attributes
Backing up the Oracle database
RMAN can only perform online (hot) backups of the Oracle database if the database is in ARCHIVELOG
mode. There are two ways to enable the ARCHIVELOG mode:
While creating a database, select the Enable Archiving checkbox; or,
Issue the following sqlplus commands for an existing database:
SQL> shutdown immediate
SQL> startup mount
SQL> alter database archivelog;
SQL> alter database open;

To back up the Oracle database:
1. Right-click on the newly created NetBackup policy and select Manual Backup.
2. Click Activity Monitor on the NetBackup admin console.
3. When the Activity Monitor indicates job completion, check the output of the script(s) indicated in the
policy. The script shows the location to which the output is written. It is usually in the same directory
as the original script, and it is similarly named.
The Activity Monitor and script output indicate the status of the backup operation.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 14



Sizing
Storage capacity needs to be sized to adequately handle the amount of data anticipated to be retained in
both native and deduplicated format. Backups that are larger than expected or contain data that deduplicates
poorly can require much more storage space. Experience and analysis have shown that there are three
distinct use cases for the DL deduplication products. Each use case has its own storage capacity needs.
Some space must always be available for new data. That amount of space, however, will depend on how
the system is used.
Immediate deduplication. With an immediate deduplication policy, deduplication may not keep up
with ingest. Systems using an immediate deduplication policy ideally should include a storage buffer
of 50 percent of the largest amount of data ingested on a single day during the week.
Immediate deduplication with fast read/restore. To ensure that data required for rapid restore is
available in native format, these systems include a storage buffer that accounts for the truncation
threshold.
Scheduled deduplication. These systems include a storage buffer that is sized for the largest backup in
native format on a single day during the week.
EMC strongly recommends performing a sizing assessment when including replication in the backup
environment.
The sizing assessment models the ingest performance and capacity required to meet the specified retention
period. If replication is selected, it also reports the replication times calculated for all days in the retention
period for the source system. The sizing assessment can help determine if replication can occur in the
desired timeframe based on the replication network bandwidth, latency of the connection between the
source and target systems, and estimated amount of data to replicate on each day. If the calculated
replication times exceed the required replication window, additional source systems may be required. There
are cases where a single source system meets capacity and ingest performance objectives, but not
replication performance as replication performance is much lower than ingest and deduplication rates.
Bi-directional replication, if used, needs to take into account the data being sent to each DL system from
the replication source. This value is added to the actual capacity needed for the system.
Refer to the EMC DL Deduplication Sizer (DLDS) Best Practices Guide for more details on the
information required to assess sizing requirements and the sizing tools available for this purpose. The most
up-to-date version of the DL sizing application and the EMC DL Deduplication Sizer (DLDS) Best
Practices Guide are available on Powerlink at (restricted audiences only):
Products > Hardware/Platforms > Disk Library Family > Sales Tools.
Space management
When a backup stream is ingested, the native data is written to the share or tape cartridge. When
deduplication occurs, the unique blocks contained in that backup are written to storage in a different
location and the metadata index of signatures and pointers representing deduplicated backup is stored. The
native format data and unique blocks present on the system represent the used storage space.
The DL retains the native format data for as long as possible to facilitate quick recoveries. If this native
data has been deduplicated for longer-term retention, data recovery will be from the deduplicated data once
the native data is removed.
Important considerations
Configure NetBackup to use expired tapes before scratch tapes as expired tapes still consume space on
the DL1500 or DL3000 until space reclamation has been run.
Expired media is not subject to space reclamation until the tape is also relabeled. Relabeling the
expired tape places it in a state that allows the space reclamation process to de-reference and
subsequently delete the unique blocks associated with the backups on that tape.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 15



Either a backup script needs to be created or properly size the number of tapes required so tapes are
relabeled as they are reused. NetBackup will always use least recently used tapes and if there are a lot
of unnecessary tapes, space reclamation will be inefficient.
Do not create more virtual tape cartridges than needed. Regularly expiring and relabeling virtual tapes
ensures efficient use of storage space.
Used storage space is reclaimed for reuse in several ways. The following describes the processes employed
for native format data and deduplicated data.
Native format data
Recovery of the storage space occupied by native format data is primarily under the control of NetBackup.
When NetBackup expires a volume, there is no direct communication of the event to the DL. This has an
impact upon DL space management when the DL is configured as a VTL. As a result, the DLs Console
Manager will still indicate that logical tape cartridge as containing data and therefore still occupying
storage space on the DL. For the DL to reuse this space, NetBackup must also relabel the logical tape
cartridge by writing a data block to the beginning of the scratch volume. Relabeling is a task that is
common to the management of physical tapes and may be performed via scripting.
To further self-manage its storage capacity, the DL monitors its available storage for user data and has a
truncation feature that begins executing automatically when used storage capacity reaches 70 percent. The
truncation feature removes the oldest native format data blocks from storage until the used storage capacity
reaches 65 percent. (These levels are 82 and 77 percent, respectively, in the DL3000 1.2 and later.) This
truncation feature operates only on fully hydrated blocks of data that have a deduplicated block counterpart.
It does not remove any native format data that does not under deduplication (deduplication policy of never)
or has not yet been deduplicated.
Relabeling tapes in NetBackup
EMC recommends using NetBackups bplabel utility, which writes a new label on the tape. This new
label is a data block written to the beginning of the virtual tape cartridge.
Note: Make sure the tape is expired before running bplabel to relabel the tape cartridge.
Deduplicated data
After NetBackup expires and relabels a volume for reuse, the DLs space reclamation process feature
identifies unique data blocks in the block pool associated with the relabeled volume. It analyzes the blocks
to determine whether they are required by any other virtual tape cartridges. It also deletes the metadata
indices associated with the relabeled volume as well as any pointers it had to unique blocks associated with
other deduplicated backups. When unique blocks are no longer referenced by any volumes, they will be
removed and the storage space they occupy will be recovered when space reclamation is performed by the
DL using the DLs space reclamation feature. The feature is set to run daily by default. This process can be
scheduled or run manually.
There is significant overhead associated with space reclamation and it best to run it during periods of low
appliance use. Replication, reclamation, and backup stream ingest all consume system resources and
therefore should not all be done at the same time without understanding overall system performance
implications.
Best practices
EMC strongly recommends scheduling the start time for space reclamation to occur after the backup(s) for
each day are complete.
Space reclamation will also be activated automatically in the event DL storage capacity reaches 95 percent
full.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 16



When used storage capacity exceeds 95 percent, the system throttles data ingest while actively performing
truncation and space reclamation until sufficient capacity is available for new data.
Phasing deduplication into the environment
EMC recommends that backup clients are phased in over time to a new DL, starting with an initial full
backup followed by the other backup types. Add similar clients gradually so that over time the device has
its block pool populated in a controlled manner.
For example, if the DL is installed during a normal incremental schedule, the initial backups to the DL are
tied to the existing technologys last full backup. If a restore is needed, data would be required both from
the previous technology as well as the DL. If the customer does not want to perform a full backup outside
the normal policy schedule, they need to wait until the full backup is to occur to begin sending data to the
DL.
Network connectivity
The DL contains six or eight Gigabit Ethernet ports for the DL1500 and DL3000, respectively, configured
as a bonded network interface by default. All six or eight ports service replication traffic, appliance
management traffic, and NAS backup data traffic.
In version 1.2 and later, there are two segmentation configuration options for the DL Ethernet ports:
Non-segmented All Ethernet ports are bonded into a single interface and utilize a single IP address.
This is the default Ethernet port configuration for the DL and the only network interface option for DL
version 1.1 and earlier.
Segmented Data traffic, replication traffic, and management traffic is separated between different
physical interfaces. Each traffic type is given its own network interface (IP address, network mask, and
gateway). This option is available in version 1.2 and later.
With segmentation, the DL traffic types can be placed on either of two physical interfaces depending on
performance or security needs. One traffic type can be isolated to a single interface while the other two
traffic types share the other interface. For example, data traffic can be isolated to a network segment and be
not visible on a common network.
Note: If the DL is configured for network segmentation, you must use the data segment IP address, not the
management segment IP address or hostname, to map CIFS shares or manage the DL. If the DL is joined to an
Active Directory domain, the Microsoft Management Console (MMC) tool, which is used to manage shares and
user/group access, may fail to connect because the system name cannot be resolved into the data segment IP
address. In this case you must specify the DL using its data segment IP address, not the hostname, by choosing the
following options in the Computer Management console: Action > Connect to another computer > Another
computer.
The bonding mode used for the DL ports on the bonded interface can be either the round-robin policy
(Mode 0), which transmits packets sequentially across all ports for load balancing and fault tolerance, or
LACP (Mode 4), which utilizes IEEE 802.3ad dynamic link aggregation. The underlying DL appliance
software and operating system manage the I/O distribution between each of the bonded ports in an attempt
to optimize the aggregate bandwidth possible across the links.
Mode 4 is available in DL version 1.1 and later. Mode 0 is available in all DL versions.
Significant performance optimization will be achieved through configuration settings on managed Ethernet
switches. For Mode 0 and Mode 4, EMC recommends using managed switches to group the physical port
connections to which the DL appliance is connected.
For Mode 0, use a managed switch with the ports used by the DL configured for "trunking" or "link
aggregation" or "EtherChannel" without LACP or pAgP to maximize performance potential. Refer to the
vendor documentation for specific instructions when configuring the port group.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 17



For example, to configure a Cisco 6500 Series switch for a common EtherChannel group, run the following
command from the Cisco switch CLI:

set port channel mod/ports... [admin_group]

mod = switch module
ports = port numbers to be added to the port channel group.
admin_group = name of port channel group (optional)

For example:
set port channel 2/1-8

For Mode 4, switches that utilize IEEE 802.3ad dynamic link aggregation allow its ports to be
automatically grouped together to form an ultra-high-bandwidth connection that greatly expands bandwidth
capacity to the network. This aggregation of DL port connections potentially improves NAS data ingest or
replication performance depending on the environment.
For example, to configure a Cisco 6500 Series switch for an EtherChannel group with LACP, run the
following commands from the Cisco switch CLI:
set channelprotocol lacp mod
set port lacp-channel mod/ports

mod = switch module
ports = port numbers to be added to the port channel group

For example:
set channelprotocol lacp 2
set port lacp-channel 2/1-8

For more information on programming EtherChannel groups and the LACP mode when using Cisco 6500
Series switches, see:
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/catos/8.x/configuration/guide/channel.html#w
p1020899
For Mode 0, all DL ports connect to the same Ethernet switch. Splitting bonded ports on a DL between
multiple switches, however, is supported on certain switches when using Mode 4. Consult the switch
vendors documentation.
When using Mode 0, make sure LACP is disabled when configuring the EtherChannel port group on managed
switches.

When using Mode 4, only connect to Ethernet switches that support IEEE 802.3ad dynamic link aggregation and
are properly configured for LACP.
Best practices
EMC recommends the following best practices when connecting the DL to the network:
Use a dedicated network by configuring a separate network or use QoS features that guarantee network
bandwidth.
Alternatively, use virtual networks (VLANs) to segregate backup from production network traffic.
Set network interface cards (NICs) for servers and clients to full duplex. Set all routers to full duplex.
Use only CAT 5e or CAT 6 cables (1 Gb/s rated cables).
If using a DNS server, verify the DNS server configuration settings are correct.
Use multiple DL Ethernet ports when connecting the bonded interface to the network. The more DL
Ethernet ports used, the better the load balancing will be across the ports.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 18



For redundancy, connect at least two DL ports to an Ethernet switch when using a bonded interface.
Set each switch port used by the DL to auto-negotiate/auto-sensing. The DL network interface cards
are preset to auto/auto and cannot be changed.
When connecting multiple DL Ethernet ports to the network when using Mode 4 (LACP), make sure
the proper LACP settings on the switch are configured. Consult the switch vendors documentation for
the configuration steps.
When using Mode 0 (balance-rr mode), use a managed switch configured for "trunking" or "link
aggregation" or "EtherChannel" to maximize performance potential. Refer to the vendor
documentation for the switch for specific instructions when configuring the port groups. Do not use the
LACP settings on the switch.
Keep the following in mind:
Concurrent operations on the DL will have significant impact on performance
The DL does not support jumbo frames.
Splitting bonded ports on a DL between multiple switches is not supported when using Mode 0.
Splitting bonded ports on a DL between multiple switches is supported on certain switches when using
Mode 4. Consult the switch vendors documentation.
When network segmentation is selected, the traffic types in the bonded interface must be on the same
subnet. The other physical interface can be on a different subnet.

EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 19



Veritas NetBackup concepts
NetBackup is based on a client/server architecture. Each NetBackup client and server belong to a storage
domain. A storage domain consists of a single master server, its associated media servers, and NetBackup
clients. The master server controls and directs all NetBackup operations in its storage domain. Each media
server controls the backup devices it is connected to. A media server can have only one master server, but a
master server can control multiple media servers. The NetBackup clients are any systems containing data to
be backed up. A master server can act as a media server, and both are capable of acting as clients.
Master server is the manager of the storage domain. An administrator can control all NetBackup
functions in the storage domain from the master server. It manages all backups, archives, and restores
and is responsible for all catalog updates.
Media server hosts one or more backup devices. Media servers are directed by the master server and
provide additional storage by enabling NetBackup to use the storage devices they control.
A client is any system with data to be backed up. The client software is specific to the operating
system on which it is installed. Normally, a client operates under the control of the master server
according to the policies and schedules set forth by the administrator.
NetBackup manages client data in increments called backup images. Backup images originate from clients
and may consist of a file, directory, file system, partition, or a database. The NetBackup file database on the
master server contains detailed information about each backup image. An entry for each backup image is
written to this database and maps the backup image to the media on which it is stored.
Licensing
Veritas NetBackup is licensed per physical machine depending on the hardware tier model of the machine.
There are separately licensed agents, options, and services that extend its functionality. Please refer to
Symantecs NetBackup documentation for licensing details.
Settings and considerations
The following describes several NetBackup settings and best practices for optimizing the backup
environment:
Avoid running disk-intensive applications such as virus scanning on the backup client when it is
backing up or restoring files.
If the source data for the backup is located on a single, non-RAID physical disk and multiple streams
are running in parallel, the source physical disk could become a performance bottleneck because of
parallel reading. Therefore, only run a single backup stream on NetBackup clients when the data to be
backed up is on a single physical disk.
Use the NetBackup 6.5 SAN client so data goes from the client to the media server across the SAN or
use a SAN media server, which only backs up itself so data doesn't go across the LAN for a more
efficient use of network resources.
Balance when backups start, rather than schedule hundreds of backups to begin at 8 P.M. For example,
schedule 50 to start at 8 P.M., another 50 to start at 8:30 P.M., and so on. Look at client completion
times, or drive activity, to balance the load.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 20



Using the DL in a NAS environment
This section covers DL behaviors to expect as well as configuration recommendations on to how to achieve
optimal performance when using it with NetBackup in a NAS environment.
General recommendations
NAS B2D shares created on the DL1500 and DL3000 can be hidden from network browsing when they are
created using the Hide this share from network browsing option.
Refer to Deduplication considerations on page 8 for additional recommendations and settings.
Backup-to-disk configurations
In a typical LAN backup-to-disk configuration, the backup image originates at the client and goes to the
media server to the NFS or CIFS share on the DL designated as the backup device. The only data sent to
the master server is the backup metadata. Setting up the backup-to-disk environment involves the following
steps:
1. Create an NFS or CIFS share on the DL. This share will be mounted (or mapped) as a backup device
on the media server. If desired, multiple shares can be created to store different collections of images.
2. Mount (or map) the share on the NetBackup media server.
a. Create a mount point for the NFS share to be used by the backup application and mount it using the
commands for your particular operating system as described in the section Mounting NFS shares
on page 21.
b. Map the CIFS share to a drive in Windows Explorer as described in the section Configuring CIFS
shares on page 23.
Mounting NFS shares
The DL can serve as a NAS appliance for backup purposes. If it is an NFS environment, access to the
shares is restricted by hostname. Root access to a NFS share is not allowed and the access rights will be
changed to nfsnobody as a security precaution.
The DL does not support NFS v4.
NFS shares created on the DL are mounted on the NFS media server in the following environments as
described in the next sections.
AIX 5.2
Enter the following command:
nfso -o timeo=600 nfs_use_reserved_ports=1
This mount command does not persist across AIX reboots. For AIX 5.2 or later, use the p option to mount the
share permanently. For releases of AIX prior to 5.2, the mount command must be included in a bootup script.
If you are using NFSv3, mount the NFS share created on the DL using this command:
mount o timeo=600 {nfs_server}:/{export path} /{mountpoint}

For example: mount o timeo=600 cosmowanda:/Q/shares/tl_nfs_1 /stoli1
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 21



To mount the NFS share on another NFS version, use the command:
mount -o vers={1|2|3},timeo=600 {nfs_server}:/{export path} /{mountpoint}

To show the list of file systems exported by the nfs server:
showmount -e {nfs_server}

and
showmount -e dfshares {nfs_server}

To show or clear the NFS statistics, respectively:
nfsstat -c [show NFS statistics]
nfsstat -z [clear NFS statistics]
HP-UX 11i
If you are using NFSv3, mount the NFS share created on the DL using this command:
mount {nfs_server}:/{export path} /{mountpoint}

For example: mount cosmowanda:/Q/shares/tl_nfs_1 /stoli1
To mount the NFS share on another NFS version, use this command:
mount -o vers={1|2|3} {nfs_server}:/{export path} /{mountpoint}

To show the list of file systems exported by the nfs server:
showmount -e {nfs_server}

and
showmount -e dfshares {nfs_server}

To show or clear the NFS statistics, respectively:
nfsstat -c [show NFS statistics]
nfsstat -z [clear NFS statistics]
Linux
If you are using NFSv3, mount the NFS share created on the DL using this command:
mount {nfs_server}:/{export path} /{mountpoint}

For example: mount cosmowanda:/Q/shares/tl_nfs_1 /stoli1
To mount the NFS share on another NFS version, use this command:
mount -o nfsvers={1|2|3} {nfs_server}:/{export path} /{mountpoint}

To show the list of file systems exported by the nfs server:
showmount -e {nfs_server}

To show the NFS statistics:
nfsstat -c [show NFS statistics]
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 22



Solaris
Mount the NFS share created on the DL using this command:
mount o vers=3 {nfs_server}:/{export path} /{mountpoint}

For example: mount o vers=3 cosmowanda:/Q/shares/tl_nfs_1 /stoli1
To mount the NFS share on another NFS version, use this command:
mount -o vers={1|2|3} {nfs_server}:/{export path} /{mountpoint}
The mount {nfs_server}:/{directory} /{mountpoint} command defaults to NFSv4 in Solaris. Attempting to mount
the share using NFSv4 results in No such file or directory error. To avoid this error, specify the NFS version
when using this command.
To show the list of file systems exported by the nfs server:
showmount -e {nfs_server}

and
showmount -e dfshares {nfs_server}

To show or clear the NFS statistics, respectively:
nfsstat -c [show NFS statistics]
nfsstat -z [clear NFS statistics]

Configuring CIFS shares
Note: If the DL is configured for network segmentation, you must use the data segment IP address, not the
management segment IP address or hostname, to map CIFS shares or manage the DL. If the DL is joined to an
Active Directory domain, the Microsoft Management Console (MMC) tool, which is used to manage shares and
user/group access, may fail to connect because the system name cannot be resolved into the data segment IP
address. In this case you must specify the DL using its data segment IP address, not the hostname, by choosing the
following options in the Computer Management console: Action > Connect to another computer > Another
computer.
If you are operating in a Windows environment, you must specify the Windows domain information in the
DL Configuration section in the DL Console Manager before you create the CIFS share. This involves
adding the name of the workgroup or Active Directory domain used by the Windows system on which the
CIFS share will be used. Once a CIFS share is created, access is allowed on a per-username basis.
Since only one value for a workgroup or Active Directory domain can be entered, either workgroup or Active
Directory domain validation will be used but not both at the same time. Also, only one workgroup name or Active
Directory domain value can be used by all Windows systems using this DL system.
1. Create a CIFS share on the DL and join a workgroup or domain type authentication domain (using the
same type as the NetBackup server or media server that will use the CIFS share).
2. Map the share as a network drive.
3. Launch the NetBackup Administration Console.
4. Under Storage > Storage Units, right-click and select New.
5. Enter the name of the CIFS share name you created on the DL.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 23



6. Choose Storage Unit type: Disk > Basic Disk.
7. Type in the absolute pathname to the share. Example: \\10.40.167.37\mycifs1
8. Click Properties to ensure that the share is accessible. If you see capacity for the share, continue with
the next step. Otherwise, correct the issue.
9. Change the number for the max concurrent jobs to your desired value.
10. Define a fragment size (recommended is 2000).
Changing the fragment size for the storage unit in NetBackup from the default value to 2000 will balance backup
and restore operations. Using this smaller fragment size allows the operation to search a more limited area of the
backup.
11. Under Device Manager/Services in Windows, edit the following services: NetBackup Client Service,
NetBackup Device Manager, and NetBackup Remote Manager and Monitor Service.
a. Open the Windows Services directory and stop all NetBackup services.
b. Select a NetBackup Service.
c. Under the Log On tab select This account and enter the media servers username and password
your media server uses to log in to its domain.
The Administrator account credentials need to match those configured for the DL.
d. Repeat steps b and c for the remaining NetBackup services.
e. When all necessary edits have been made, restart the NetBackup services and exit the Services
directory.
12. Launch the NetBackup Administration Console.
13. Define the policy for a NetBackup job to use with the DL.
14. Right-click on the policy you created and choose Manual backup to test the setup.
Performance tuning
The following describes some steps you can take to determine bottlenecks and improve performance.
To improve performance on disk storage units and disk staging storage units
1. Increase the data buffers used by the Veritas NetBackup disk manager process on the master and media
servers. The default value is set to 262144 (256K).
2. Create the following file (this filename is case sensitive) and add the value 1048576 to its contents:
<install path>/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS_DISK
3. Create the following file and add the value 16 to its contents:
<install path>/netbackup/db/config/NUMBER_DATA_BUFFERS_DISK
Note: The value of 16 can be increased based on available memory.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 24



Testing the source data to isolate bottlenecks
Use the following to troubleshoot slow performance. The bpbkar command will show how fast data can be
read from the hard disk.
A note on command syntax: The "<path-to-read>" is the path to the directories to back up and the "> /dev/null" is
where the files list will be sent along with the report regarding the speed of reading the data from the disk.

On UNIX systems

./netbackup/bin/bpbkar -nocont <absolute-path-to-read> > /dev/null
For example: ./netbackup/bin/bpbkar -nocont /home > /dev/null

On Windows systems

.\netbackup\bin\bpbkar32 -nocont <absolute-path-to-read> > NUL 2>temp.f

For example: .\netbackup\bin\bpbkar32 -nocont C:\ > NUL 2>temp.f
The starting point for reading data for the path in the Windows example is C:\.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 25



Using the DL in a SAN environment
The DL, when used with its optional virtual tape library feature, can be configured to look like a number of
tape libraries with associated tape drives to the backup servers on the SAN. When using the DL with
NetBackup, however, you must configure it as specified on the NetBackup VTL HCL and with one of the
supported tape drive emulations. The NetBackup 6.5 HCL is at:
ftp://exftpp.symantec.com/pub/support/products/NetBackup_Enterprise_Server/284599.pdf
This section covers DL behaviors to expect as well as configuration recommendations on how to achieve
optimal performance when using it with NetBackup in a Fibre Channel SAN environment. In this
environment, data is sent directly from the client to the DL VTLs. Only metadata is transferred over the
LAN from the client to the server.
The virtual tape library (VTL) feature is a licensed option of the DL1500 and DL3000 and is used only in
SAN environments.
For the NetBackup versions and supported operating systems, refer to the EMC Support Matrix on
Powerlink.
Media expiration
When a tape is expired by NetBackup, there is no direct communication of the event to the DL. As a result,
the tape may display as empty or SCRATCH in the NetBackup GUI, but this same tape will appear in the
DL Console Manager as containing data. This indicates the data on the expired tape is still using space on
the DL. To reclaim this space in the DL, EMC recommends using NetBackups bplabel utility, which
writes a new label on the tape. This new label is a data block written to the beginning of the virtual tape
cartridge.
The DL virtual tape cartridge will act similar to a physical tape and the data after the label becomes no
longer accessible. Space reclamation can occur at its scheduled time or started manually from the DL.
DL SAN attach
The DL1500 has two 4 Gb Fibre Channel ports and the DL3000 has four 4 Gb front-end Fibre Channel
ports for target mode Fibre Channel attach.
The following recommendations apply when connecting a DL to a backup server via a Fibre Channel
switch:
When emulating an EMC Disk Library, use a Fibre Channel switch listed on the EMC Support Matrix.
Avoid using hard (port) zoning schemes with backup devices.
Always use a single-initiator single-target zoning scheme by world wide port name (WWPN).
Switch encryption solutions are not supported by the DL. This product provides an inline encryption
feature with the optional replication feature to meet data in-flight encryption requirements.
Limit FC extended fabric (ISL link) configurations to three hops between the backup server and the
DL.
Device discovery (persistent binding)
When an operating system scans its storage buses (Fibre Channel or SCSI) for devices, it may assign a
particular device to a different device name than it used during a previous scan. Since backup software
saves information about the device names of the various tape drives it sees in its database during the
configuration process, device reassignment during a scan will impact the availability of backup devices to
the application.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 26



Persistent binding is the ability to fix a particular device to a particular device name. In general, this is done
by associating a WWPN (and possibly a LUN) or a SCSI target ID with a device name so that the operating
system can maintain persistence of a particular device to a specific device name. The method for doing this
varies for different operating systems and Fibre Channel cards. Some environments require the tape drive
driver to also be configured for persistent binding.
If persistent binding is improperly configured, the operating system may provide a device with multiple
names giving a device one device name after a boot, but giving it a different name on a subsequent boot.
Device drivers
NetBackup requires specific tape drive drivers or driver settings. These drivers are set up directly in the
operating system that will use the virtual tape drives within the virtual libraries.
If you create virtual libraries that use the same type of tape drives you have been using in your backup
environment, you can probably continue using the same tape drivers. This is preferable since proper
operation has most likely already been verified. If you decide to use a different type of tape drive, or you
are implementing a different backup scheme than previously configured, you may need to install new
device drivers for the virtual tape drives.
Windows drivers
In general, the tape drive vendors drivers are required for Windows.
The vendor tape drive drivers can be downloaded from the tape drive vendor websites:
HP device drivers
http://h20180.www2.hp.com/apps/Lookup?h_lang=en&h_cc=us&cc=us&h_page=hpcom&lang=en&h_clie
nt=S-A-R163-1&h_pagetype=s-002&h_query=LTO&submit.x=4&submit.y=5

IBM device drivers
ftp://ftp.software.ibm.com/storage/devdrvr

Always install an IBM tape device driver per the instructions provided with each driver. Read the driver
documentation carefully
DL emulated IBM tape drives do not support IBMs Dynamic Path Failover (DPF) or Control Path Failover
(CPF). Consult the driver documentation on how to disable these features.
In Windows environments, use releases 6.0.6.8, 6.1.3.5, or later only. Do not use any driver revisions
between versions 6.0.6.8 and 6.1.3.5.
STK tape drive drivers
http://www.storagetek.com/support/drivers

The DL does not emulate any STK (now Sun) tape drives.
Sony device drivers
http://sony.storagesupport.com/models/1?tab=drivers

The DL does not emulate any Sony tape drives.

Quantum device drivers
http://www.quantum.com/ServiceandSupport/SoftwareandDocumentationDownloads/Index.aspx

EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 27



UNIX drivers
For UNIX platforms, refer to the NetBackup Media Manager Device Configuration Guide for Unix for
specific tape drive driver information.
Scanning devices
The operating system can scan for new devices. If all devices are not detected, a gap may exist in the LUN
numbering. NetBackups scan command located in /usr/openv/volmgr/bin/goodies/scan can be used to
ensure that all virtual tape libraries and their drives are visible to the operating system.
Run Configure Storage Devices from the NetBackup Administration Console to scan, detect, and
configure new storage devices.
Configuring the backup server
NetBackup operates in a client/server model consisting of servers, clients, and storage devices. When
backing up to a virtual tape library on the DL, the media server sends the data over the SAN to the DL. The
backup metadata associated with the backup goes from the backup client to the master server over a LAN
where it is stored in the master servers database.
1. Create a virtual tape library on the DL, specifying the emulation type, number of slots, number of tape
drives, and their emulation type. This VTL will be a backup device on a NetBackup media server or
master server (if it is also configured as a media server). If desired, multiple VTLs can be created to
service different media servers.
2. Create virtual tape cartridges on the DL for the VTL specifying the cartridge type, quantity, and
capacity.
3. Assign the VTL to a media server on the SAN to which the DL is attached.
4. Scan for devices at the NetBackup media server. The VTL and its tape drives will appear.
Simultaneous backups
The DL1500 and DL3000 emulate a number of tape drive types. These appliances support multiple virtual
libraries and tape drives simultaneously.
To address backup bottlenecks commonly seen with shared devices, two solutions can be deployed:
Create a library and tape drives for each media servers exclusive use to ensure the best possible
performance.
Create a single library with many tape drives, but only assign a few tape drives to each media server.
In this configuration, each media server has its own dedicated resources. This also simplifies the initial
installation and avoids any driver-related issues you could run into when sharing a tape device between
unlike OS platforms.
With either solution, it is a good practice to limit the number of virtual tape drives so when all are servicing
I/O at the same time each drive can sustain at least 20 MB/s. You may need to stagger backups to support
fast and slow datastreams to obtain maximum utilization of the available bandwidth.
Single library with multiple hosts
For multiple hosts to use the same devices, the DL requires you to create different groups for each host. A
group consists of exactly one host, one target, and one or more devices. The DL does not permit multiple
hosts to access the same group.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 28



Virtual tape libraries
Until a virtual library is assigned to a SAN client (media server to which the DL is attached), it is not
enabled for use by the media server. To ensure correct library behavior when assigning or unassigning
virtual libraries, ensure that device numbering on the bus starts with LUN 0 and that there are no LUN
numbering holes. LUN numbering holes can occur when devices are unassigned.
To change the LUN values, use the DL Console Manager as follows:
1. Go to Configuration.
2. Select SAN Clients.
3. Select Edit.
4. Change the LUN values for the device list as necessary.
Virtual tape cartridges
The DL does not preallocate disk space when it creates a virtual tape cartridge. As such, there are several
factors to consider.
The virtual cartridge size represents the amount of native format data that can be stored uncompressed
by that tape.
Although a large number of virtual tapes can be created, it is very important to take into consideration
cartridge reuse. When too many tapes are available, NetBackup will continue to use new cartridges
rather than those available in the scratch pool. The DLs space reclamation process will not be able to
recover space occupied by tapes that are no longer needed.
The cartridge size can be customized but cannot exceed the capacity of its physical equivalent. This
ensures that the compressed data stored on a virtual tape cartridge will fit on a physical tape once it has
been decompressed and then recompressed by the physical tape drive. The DL1500 and DL3000 will
not allow you to create tape cartridges larger than their physical equivalents. A size of 100 GB has
been found to be a good minimum virtual cartridge size.
If you intend to leverage the Path-to-Tape option, create virtual tape cartridges of the same type as the
physical tape used in the PTL (if possible) or the same virtual cartridge type in a DL4000 Series. If your
PTL uses a tape type that the DL does not emulate, configure the virtual tape cartridges as LTO-1.
Best practices
EMC recommends the following when creating and using virtual tape cartridges:
Creating smaller-size media is preferred. It allows a virtual tape cartridge to be filled, even when
backing up smaller data sets. It also aids in the transfer of data from virtual to physical media.
Consider creating only enough media to accommodate the amount of backup data for the required
retention period.
Regularly expire and relabel tapes to avoid running out of storage capacity and allow space
reclamation to complete within the daily schedule. If tapes are expired and relabeled only occasionally,
depending on the amount of data represented by those tapes, space reclamation can take several days to
run and as such impact other system processes.
Performance tuning
There are three settings in NetBackup that have been shown to have a major performance impact for
backups. These are the size of the data buffer, the number of the data buffers, and the size of the network
data buffers.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 29



SIZE_DATA_BUFFERS
The default SIZE_DATA_BUFFERS setting specifies a block size of 65536. The recommended value is
262144. (Note: For a Windows 2003 server, SP2 must be installed to use this block size. If SP2 is not
installed, the default setting must be used.)
After changing this value, it is important to test both backups and restores, as sometimes data can be
written at the modified size, but potentially cannot be read at the modified size. If the shared storage option
(SSO) is used, take care to change SIZE_DATA_BUFFERS on all media servers or it may not be possible
to restore.
NUMBER_DATA_BUFFERS
In combination with the change in block size, the number of data buffers used will impact overall system
performance. The default setting for the number of data buffers used is 16. Increasing the number of buffers
allows more data to be buffered before being sent to the device. The recommended value is 32.
NET_BUFFER_SZ
NOTE: The NET_BUFFER_SZ setting only applies to NetBackup clients that send data to a media server over the
network.

When a backup is initiated, the client packages data of the amount specified by the Buffer_Size value, and
transfers the information to the media server, which in turn, buffers that data in NET_BUFFER_SZ. When
the NET_BUFFER_SZ is full, it transfers data to the array of space created by a combination of
NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS. As soon as at least one of the
SIZE_DATA_BUFFERS is full the information is written to the tape drive. Improved performance has
been achieved by matching the Buffer-Size on the clients to the NET_BUFFER_SZ on the media server.
Windows Server 2003 in a SAN environment
According to Microsoft, a conflict in Windows Server 2003 causes a Test Unit Ready (TUR) request issue
on SCSI-attached and fiber-attached devices. When this issue occurs, an overflow of TUR requests causes
the storage unit not to respond or to respond slowly to SCSI commands. In a SAN environment, any
Windows Server 2003-based computer that is zoned to detect the TBU hardware can send TUR requests.
The subject is referenced in Microsoft support article 84241: http://support.microsoft.com/kb/842411/en-us


EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 30



Copying to tape
There are many options for copying backups on virtual tape to physical tape for long-term data retention.
Physical tapes can be created directly from virtual tape using DL copy-to-tape options or with the standard
method of copying with NetBackup.
The DL has two copy-to-tape options:
Backup application specific Path-to-Tape (PTT)
Auto Archive
The DL copy-to-tape options require the connection of a physical tape library to port 3 of the DLs HBA. The
respective feature licenses, when installed, convert this port from a target to an initiator. As an initiator port, port 3
of the HBA will no longer support Fibre Channel host connectivity. Only one of these options can be licensed at a
time on the DL.
For detailed information on the DL backup application specific PTT or Auto Archive options, refer to the
EMC DL1500 and DL3000 Copying to Physical Tape Best Practices Planning white paper.
SAN attachment
A DL3000 has four Fibre Channel ports for SAN attach and a DL1500 has two Fibre Channel ports. The
default roles of these ports are as target ports. When you install the DLs Path-to-Tape (PTT) or Auto
Archive license, one port, FC Port 3, becomes an initiator port. This initiator port is used to attach a
physical tape library or an EDL VTL to be used by the PTT or Auto Archive feature.
Special considerations
Use single initiator, single target zoning by WWPN.
Avoid hard port zoning practices with backup devices.
If this is a TLU or VTL with multiple FC target ports, make a separate zone for each port for each
initiator (DL and media server).
Once the PTT or Auto Archive license has been installed/enabled, the associated Fibre Channel port is
configured as an initiator port to support the copy-to-tape function and cannot be reconfigured as a
target port.
Backup application specific Path-to-Tape
Path-to-Tape (PTT) is a licensed option of the DL1500 and DL3000 and is used only for copying backup
images from virtual cartridges onto physical tape or a virtual cartridge in an EDL VTL under the direction
of the backup application. This feature cannot be used to copy NAS backups CIFS shares or NFS mount
points to tape. Nor can this feature be used to import physical tapes to virtual tape.
The DLs optional PTT feature makes use of NDMP commands implemented internally to copy backup
images directly from a virtual tape cartridge to physical tape in an attached PTL or virtual tapes in an
attached EDL VTL under the direction of NetBackups NDMP Direct Copy option. The PTT feature does
not utilize the media server for this copy operation, thus freeing up resources on the media server. The
NetBackup catalog contains all the tape copies performed in this fashion.
The NetBackup Direct Copy option uses NDMP as a control protocol to tell the DL appliance to duplicate a
backup image on a virtual tape cartridge A to a physical tape or virtual cartridge B in an attached
destination device. When the media server initiates the copy, the cartridge to be copied is loaded into a
drive in the source virtual tape library and positioned to the start of the backup image to be copied. The
destination tape is loaded into a drive in the physical or virtual destination library, labeled (or its label is
verified), and positioned to the proper location, and NetBackup writes a backup header. Then the NDMP
tape server software in the DL is instructed by NetBackup to copy the backup image from the source virtual
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 31



tape cartridge to the destination media. The DL undeduplicates the data (if deduplicated) and copies it to
the destination media, telling NetBackup when the duplication process completes. If the destination tape
becomes full during the copy operation, NetBackup will put that tape back into its slot in the library, load
another tape into the drive, label it (or verify its label), and continue the copy operation. NetBackup records
which tape received the copy. Using this method, NetBackup catalogs and tracks both the virtual and
physical tapes. Restores can also be performed directly from either copy.
The copies generated by the PTT feature can be read with any tape device without the use of a DL. In other
words, the data on the tape is written in an undeduplicated native tape backup format, with a different (BSP
catalog aware) barcode.
For more information, refer to the section on Configuring NDMP Direct Copy in the Veritas NetBackup
for NDMP Administrators Guide from Symantec:
ftp://exftpp.symantec.com/pub/support/products/NetBackup_Enterprise_Server/290205.pdf
Site requirements for backup application specific PTT
Requirements are as follows:
DL with VTL and PTT licensed features installed
NetBackup Library Based Tape Drive license(s) installed on the NetBackup master and media servers
for tape drives in the physical tape library
NetBackup Shared Storage Option license(s) installed on the NetBackup master and media server for
any tape drives shared in the physical tape library
NetBackup Enterprise Disk Option license(s) installed on the NetBackup master and media server for
licensing of the NAS or VTL version of the DL
Physical tape library or EDL VTL
Best practices
When using the Path-to-Tape option with NetBackups NDMP Direct Copy, be aware that all virtual
devices configured on the DL become available to the media server accessing the DL as an NDMP
host. This includes all other VTLs defined on the DL and assigned to other DL SAN client groups.
NetBackup is capable of labeling or overwriting those other SAN clients tapes, potentially resulting in
data loss unless you take extraordinary measures during the media server NDMP configuration process
to remove VTLs used by other media servers from the NDMP device configuration.
Label all tape cartridges for the NDMP device and place them in a separate media pool that will be
used for duplication jobs.
The DL supports attaching a single physical tape library (PTL) to its FC Port 3. For best performance
when using a PTL, assign only one tape drive resource in the PTL as a path-to-tape device or limit the
copy jobs so that only one physical tape drive is doing copy I/O. Using too many tape drives could
result in poor performance due to excessive shoeshine activity in the tape drive.
Shoeshining doesn't occur with the virtual tape drives of a VTL. However, above eight datastreams,
performance with the virtual tape drive begins to fracture into slow streams and faster streams. If
balanced performance is something you want, consider limiting the number of virtual tape drives to
eight.
Schedule copy to physical tape operations to occur during windows of non-backup activity. Avoiding
concurrent front-end I/O will improve tape copy performance and minimize shoeshine activity by the
physical tape drive.
When duplicating to an EDL VTL, ensure that the virtual tape cartridges on the DL and the EDL VTL
are the same type.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 32



To duplicate a virtual image
NetBackup uses NDMP Direct Copy when you duplicate a backup image that any NetBackup policy
created as long as (1) the destination is an NDMP storage unit in a VTL or in a physical tape library; and
(2) an NDMP tape drive is available to mount the source image.
The policy need not be an NDMP policy. To duplicate a backup image, you can use any of the following
NetBackup options:
The Duplicate option in the Catalog node of the NetBackup Administration Console.
NetBackup Vault. Refer to the Veritas NetBackup Vault Administrators Guide.
(http://seer.entsupport.symantec.com/docs/290233.htm)
The bpduplicate command. Refer to the Veritas NetBackup Command Guide that applies to your
platform.
(Windows: http://seer.entsupport.symantec.com/docs/290235.htm;
UNIX and Linux: http://seer.entsupport.symantec.com/docs/290234.htm)
Storage Lifecycle Policies in NetBackup 6.5 and later
Restoring
NetBackup designates a primary copy for each backup. The primary copy is used by NetBackup to
restore that backup and is, by default, the original. If the primary copy of a backup set is unavailable, but
has not yet expired, it will be necessary to change the duplicates properties to primary copy in order to
restore that backup.
To promote a duplicate to primary copy, you can use any of the following NetBackup options:
The Set Primary Copy action in the Catalog node of the NetBackup Administration console
The bpchangeprimary cli command
The bpduplicate command
After promoting the duplicate to the primary copy, use the Backup, Archive and Restore interface on a
client to list and restore files from the backup. Refer to the online help in the Backup, Archive, and Restore
client or the Veritas NetBackup 6.5 Backup, Archive, and Restore Getting Started Guide
(http://seer.entsupport.symantec.com/docs/290206.htm) for more information on the restore procedure.
Auto Archive
DL version 1.1 and later support connecting a physical tape library or EMC Series 4000 Disk Library to the
DL and automatically exporting virtual tapes to corresponding physical tapes or virtual tapes as well as the
importing of physical or virtual tapes to virtual tapes in the DL. The Auto Archive feature supports the
following physical or virtual tape library models: Quantum iScalar 2000, iScalar 500, PX720, and PX500
only with IBM LTO-2, LTO-3, or LTO-4 tape drives.
Auto Archive is a licensed option of the DL1500 and DL3000. Unlike backup application specific PTT,
these copy operations do not utilize NetBackup. Auto Archive operations are managed from the DLs
Console Manager. All data is copied in native format.
Auto Archive provides the following capabilities:
Auto archive Copies the virtual tape to a physical tape and retains the virtual tape
Export Copies the virtual tape to physical tape and deletes the virtual tape
Import Copies the physical tape to virtual tape

The main advantages of Auto Archive are:
No CPU cycles and no I/O bandwidth resources are consumed on the backup server.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 33



The backup server does not need to be connected to both the DL and the physical tape library.

When using Auto Archive, keep the following in mind:
There is a possibility that the entire contents of the virtual tape may not fit on the physical tape. The
default virtual tape size accounts for usable tape capacity, which may vary from manufacturer
specification.
The tape copy must match the format of the virtual tape. It is not possible to copy to a different tape
type.
Only the native tape format supported by the tape drive is supported. For example, with LTO-3 tape
drives, use LTO-3 tapes.
Manual record keeping is involved unless the backup software contains some type of vaulting software
to track offsite cartridges.

When a virtual tape is archived or exported to a physical or virtual tape, the tape copy is identical to a tape
that was written directly by NetBackup and can be used to restore files directly on a system (without the
DL). The restore environment must conform to certain rules:
NetBackup must be used to restored the tape.
The same type of tape drive must be used as that which wrote the physical tape.
Auto Archive site requirements
DL with both VTL and Auto Archive licensed features installed
Destination library (physical tape library or EDL VTL) of the supported type (Quantum iScalar 2000,
iScalar 500, PX720, and PX500 only with IBM LTO-2, LTO-3, or LTO-4 tape drives)
VTL configured on the DL of the same emulation type as the physical tape library or EDL VTL being
used
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 34



OpenStorage (OST) API support
OpenStorage (OST) is a feature of Symantecs Veritas NetBackup. OST integrates NetBackup with disk
backup devices, such as the DL. OST enables NetBackup media servers to communicate with disk devices
without employing tape emulation.
The OST option of the DL makes disk volumes called Logical Storage Units (LSUs) available to a media
server. Multiple NetBackup media servers, each with the DL OST plug-in installed, can use the same LSU
on a DL as a disk volume.
The NetBackup system sets policies that control when backups occur while the DL performs data
deduplication and replication. Backups, replication, and restores are managed from a single NetBackup
console and can use those DLs features exposed to it through the client plug-in. NetBackup manages all
images (collections of data) in the NetBackup catalog, even when the DL creates the images.
An OST solution provides centralized management and storage capabilities such as:
Shared disks. Multiple NetBackup media servers can access the same disk volume concurrently.
Load balancing and performance. NetBackup balances its backup jobs and storage usage by choosing
the least full disk volume and least used media server in the environment.
DL data deduplication and replication. Images backed up to the DL using OST are deduplicated and
can later replicate to another DL without requiring any user intervention.
NetBackup optimized duplication. NetBackup leverages the DLs ability to replicate deduplicated
images to efficiently duplicate an image from one DL to another.
Since NetBackup is managing the duplication of LSU data, multiple targets can be configured through
the Storage Lifecycle Policies in NetBackup with NetBackup aware of all copies.
Replication of OST images does not require a DL replication license. However, improved replication performance
of OST images can be achieved when a replication license is present and an OST image is configured for both DL
replication and NetBackup optimized duplication.
No special installation is required for the NetBackup components of OpenStorage. However, the following
is required:
The NetBackup master server and all NetBackup media servers that use the feature must be at
NetBackup 6.5.3 or later. EMC recommends using NetBackup 6.5.4 or later.
There is a known limitation with NetBackup 6.5.3 and earlier where backup images cannot span disk
volumes within a disk pool. If the size of the backup exceeds the available capacity in a disk volume, the
backup fails and NetBackup reports a media error.
You must activate the feature by installing NetBackups OpenStorage Disk Option license key on the
NetBackup master server.
OST API client plug-in (available from EMC) installed on all NetBackup media servers that connect to
the DL. To obtain the plug-in, go to the EMC Powerlink website (http://powerlink.emc.com) and
select Support > Software Downloads and Licensing > Downloads D > Disk Library.
DL OST license (available from EMC)
DL version 1.1.3.3 and later support a client plug-in for Solaris, Linux, and Windows. Refer to the EMC Support
Matrix on Powerlink for a list of operating systems compatible with the OST feature.
More information on replication can be found in the EMC DL1500 and DL3000 with Veritas NetBackup
OpenStorage (OST) Best Practices Planning white paper on Powerlink.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 35



NetBackup optimized duplication
Optimized duplication, also referred to as OST replication or optimized copy, is another duplication option
of NetBackup. Using NetBackup duplicate methods, you can leverage DL replication to duplicate a
deduplicated backup image from one DL disk pool to another DL disk pool. The duplicate operation of
NetBackup will trigger the replication function in the DL if both the source and destination volume are
OST disk volumes. The DL performs the copy to the target DL, offloading the NetBackup media servers.
Only the unique data not present in the source LSU copies to the target LSU, reducing bandwidth
utilization.
To perform optimized duplication with the DL, the source and destination disk pools must be DL disk
pools. The media server that initiates optimized duplication must connect to and have access credentials to
both the source and target DLs to confirm the copy of the image occurred and maintain records of the
image copies and their locations in the NetBackup catalog.
General considerations when using optimized deduplication
Because NetBackup optimized duplication uses DL replication to copy data, many of the same
considerations around network performance and sizing that apply to DL replication also apply when
optimized duplication is used. When using NetBackup optimized duplication to copy images to another DL
system, keep the following in mind:
Always assess the network between the source and target DL systems in both directions. This will
ensure that sufficient bandwidth is available to support the maximum amount of data to be replicated
within the replication window. This can be done by performing a formal assessment if necessary.
Seeding of the target system is almost always required. (See Seeding (pre-populating the target
system) on page 40.)
Do not place the source and target DL systems into production until required optimized duplication
windows are met. When optimized duplication falls behind (exceeds the copy window), it is hard to
catch up.
If an optimized duplication job fails, NetBackup will retry the copy operation using its normal
duplication. Since this operation duplicates the native source image using the media server, the copy
will take considerably longer, possibly impacting the copy window as well as the efficiency of other
DL and NetBackup operations.
General considerations when using optimized deduplication with a DL replication
license
Major advantages of using NetBackup optimized duplication with a DL replication license include:
Unique data written to a disk volume (LSU) continuously transfers to the target DL as it deduplicates
instead of waiting until the duplicate trigger occurs. Since most or all of the data associated with the
image to be duplicated is present at the target when NetBackup issues the duplicate trigger, the copy is
available much sooner.
If all the deduplicated data associated with the image to copy is already at the target DL when the
duplicate trigger occurs, only the metadata description associated with that image needs to replicate at
that time.
AES-128 encryption can be optionally enabled for storage servers configured for DL replication
Some disadvantages of this configuration are:
Replication of VTL, NAS, and/or OST data can only occur to the same target DL system.
Optimized duplication performance gains are not realized if DL replication of a storage server is
configured for a target DL system that is different from the OST optimized duplication target system
for that storage server. In this case, NetBackup would be unaware of the OST images replicated to the
DL replication target system.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 36



It requires both the NetBackup optimized duplication setup as well as DL replication configuration of a
storage server. Individual LSUs are not configurable for replication.
Note: When using NetBackup optimized duplication with DL replication, the replication configuration involves
enabling replication only on the storage server. No namespace schedule (Replicate Daily at ) or Sync ID is
specified. The NetBackup duplicate trigger will ensure that the metadata description of the OST image copies to
the target disk volume.
Configuring NetBackup optimized duplication
There are three methods that can be used to perform NetBackup optimized duplication of deduplicated
backup images from a source DL disk pool to a target DL disk pool. One method is to use the CLI to
perform the duplication either manually or by writing a script that runs at a specific time.
The second method uses Storage Lifecycle Policies (SLP) to first back up an image to the DL and later use
the DL to replicate the deduplicated image to another DL. Although this optimized duplication process is
automated, it does not allow scheduling of when the duplication occurs, which the Vault option does allow.
The third method for duplicating backup images is to use the NetBackup Vault option. The Vault option
allows you to schedule and automate the duplication process.
Optimized duplication has the following NetBackup limitations:
Failure of an optimized duplication operation causes the duplication to be retried as a normal
duplication.
To confirm the image copy, a media server initiating the optimized duplication must have connectivity
to the target DL.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 37



Replicating deduplicated data
DL replication does not utilize the backup application. Replication is managed by the DL and manual tracking of
the replicated copies is required.
Replication is an optional licensed feature and is supported in the following configurations:
DL1500 to DL1500
DL3000 to DL3000
DL1500 to DL3000
DL3000 to DL1500
The DL systems involved in a replication configuration must be running the same major level of firmware. That is,
version 1.1.x systems replicate to a target system running version 1.1.x. Likewise, version 1.2.x systems replicate
to a target system running version 1.2.x. Replication between version 1.1.x and version 1.2.x systems is not
supported.
DL replication occurs in two stages. First, a copy of the unique data associated with each replication-
enabled VTL/share that is not already present at the target DL transfers to the target DL as the data
deduplicates. This is referred to as continuous replication. Second, a metadata description of the replicated
VTL/share or cartridge or directory/file is sent to the target system. This second stage ensures that a
recoverable image is available on the target DL. This second stage is referred to as namespace replication.
In version 1.1 and later, there are two variations of namespace replication:
VTL/NAS share-level replication (as is in version 1.0)
Individual tape cartridge or directory/file replication
With VTL/NAS share replication, a VTL or NAS share is made available as a recovery point when its
metadata description is replicated to the target system. This replication of the metadata description can be
scheduled once every 24-hour period (version 1.1 or earlier) or up to once per hour (version 1.2 and later)
or be done manually as many times as desired. The 10 most recent recovery points (24 in version 1.2 and
later) of a NAS share/VTL are available on the target DL for selection.
With individual tape cartridge or directory/file replication, the tape cartridge or directory/file becomes
readable on the target DL as soon as its metadata description is replicated. This replication of the metadata
description occurs when a tape is unmounted when using cartridge-based replication or when a CLI
replication command is issued when using directory/file-based replication. The VTLs and NAS shares on
the target DL contain the most recent copy of each replicated tape or directory/file.
Failure to perform a namespace replication of a replication-enabled VTL or NAS share will result in no recovery
point or available cartridge or directory/file on the target DL.
See Appendix: Using replication with NetBackup on page 42 for an example of using NetBackup with
the DLs directory/file-based replication feature.
More information on replication can be found in the EMC DL1500 and DL3000 Replication Best
Practices Planning white paper on Powerlink.
Replication considerations
Replication transmits data over Ethernet using TCP. The source DL can optionally encrypt the data using
AES-128 before sending it across the TCP link to the remote DL where it is unencrypted before it is stored.
The DL uses TCP port 1062 for replication of the unique data and port 80 for replication of the metadata
description. There is no physical Ethernet port on the DL reserved for the replication feature. See Network
connectivity on page 17 for recommendations when connecting to the network.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 38



When adding DL replication to the backup environment, keep the following in mind:
Always assess the network between the source and target systems in both directions as part of the test
and acceptance process and prior to putting the systems into production. This will ensure that sufficient
bandwidth is available to support the maximum amount of data desired to be replicated within the
replication window. This can also be done by performing a formal assessment if necessary.
Use ping or similar analyzer software to get an idea of latency between the two systems as well
as to determine if any network bottlenecks are occurring. Run this test multiple times on different
days at different times to confirm the numbers.
Use the Console Managers built-in Performance Analyzer (Figure 3) to measure network
performance between the two systems.

Figure 3. Network performance analysis
Make sure both the source and target DLs are configured for replication before performing any
backups to the source DL.
Seeding of the target system is almost always required. See Seeding (pre-populating the target
system) for recommended options.
Do not place replication configurations into production until required replication windows are met.
When replication falls behind (exceeds the replication window), it is hard to catch up.
Consider using immediate deduplication to effectively extend the replication window and lower the
chance of falling behind. Since replication is initiated when deduplication begins, this enlarges the
replication window to maximize the amount of data that can be transferred should change rates
increase unexpectedly, an unusually large amount of data is backed up, or excessive network traffic
slows data movement.
Replication performance depends on daily change rates between new backup data and data residing on the
target system.
The higher the change rate, the more data that needs to be moved within the replication window.
Lower than expected deduplication rates will add time to the replication and may exceed the required
replication window.
If deduplication is slowed, continuous replication will also be slow. Deduplication can be slowed by
poor ingest rates, fragmentation, and other factors that affect the speed at which block level match
detection can occur.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 39



Network latency will have a significant impact on replication performance.
128-bit AES encryption for replication is available. Encryption may affect replication performance. It
should be disabled if the customers WAN is already secured.

If you have opted to do VTL/NAS share-level namespace replication, the length of time it takes to verify
that all data associated with that VTL/NAS share is present at the target DL will take longer and longer as
the amount of data increases. This will impact the speed at which a recovery point is available on the target
DL as the metadata description of that VTL/NAS share cannot replicate to the target DL until the
verification completes. Consider the following options:
Use smaller VTLs or NAS shares targeting specific data and performing rolling backups to these
VTLs/shares to spread the replication out over time and allow the replication process to work with
easily managed data sizes.
Use cartridge-level or directory/file-level namespace replication instead. Because a data verification
step occurs at the cartridge or directory/file level, the delay that can occur before the metadata
description replicates is substantially reduced unless you append to large cartridges. In this case,
always overwrite or use new cartridges or limit the size of the cartridge.
Seeding (pre-populating the target system)
Initial replication (first data copy) is a time-consuming operation and will usually take significantly more
time than later replications because the data is typically new and unknown to the target DL.
For replication, the goal is to facilitate the transfer of the large amount of unique data produced by initial
backups to the source shares/VTLs to the target DL. This is done by seeding the target DL with the same
data as on the source DL so that only the minimum amount of data needs to be transferred between units on
subsequent replications to maintain synchronization. The source and target systems should not be put into
production until this seeding process is complete. Seeding is considered complete when the required
replication window has been demonstrated to have been met.
There are a number of options that can be employed to accomplish this:
OPTION 1: Locate the source and target DL so that they are on a dedicated Ethernet network and
replicate locally. This will allow replication to proceed at the fastest possible network rate. EMC
recommends replicating at least two full backups in this local configuration to demonstrate replication
savings. If savings are not seen, further local replications may be needed to ensure the target system
has sufficient data. (That is, the data transferred by subsequent replications is more representative of
the quantity of data that will typically replicate within the window.) When the seeding completes, the
target DL can be deployed to its intended location.
OPTION 2: Locate the source and target DL so that they are both connected to the storage node, and
use the storage node to perform an inline copy or dual write of data from at least two full backups to
the source and target systems, using a temporary NAS share or VTL on the target DL. Deploy the
target DL to its target location and perform a namespace replication of the VTL/NAS share. Delete the
temporary NAS share or VTL on the target DL as well as references to the temporary copy in the
backup application catalog.
OPTION 3: Use tape to seed the data in the target DL. Using the tapes from at least two full backups
present on the source DL, write the data to temporary NAS shares or a VTL on the target DL. Perform
a namespace replication. Delete the temporary NAS share or VTL on the target DL as well as
references to the copied save sets/images in the backup application catalog if the tape copy was
performed by a backup application.
The goal of Options 2 and 3 above is to write native backup data directly to the source DL and target DL and
allow each system to deduplicate the data.
If replication is not enabled for a NAS share or virtual tape library until multiple backup streams destined
for that particular virtual device or NAS share are ingested, there will be a large number of unique blocks
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 40



on the source DL that will need to be transferred over the network when the first namespace replication
occurs. In this situation, the data verification performed as part of the namespace replication will detect that
all the unique blocks on the source system must be sent over the network and there may be a significant
delay before the data in the two systems is synchronized.
If there are disruptions during the replication process for any reason (for example, a network infrastructure
problem), re-seeding may be necessary to eliminate a large replication backlog that can occur as a result of
the disruption. Large backlogs, when they exist, make it difficult for the systems to resynchronize.
Space management considerations
When using cartridge-level or directory/file-based namespace replication, it is necessary to regularly
execute the synchronization feature. It is available through the Console Manager where it can be run
manually and as a CLI command for scripted operation.
Synchronization removes tapes or directories/files in the corresponding target VTL or share on which it is
run that are no longer present on the source system. It marks the associated data as eligible for space
reclamation on the target DL. EMC recommends regularly running synchronization to ensure that unneeded
data does not accumulate on the target DL causing it to fill unnecessarily.
Recovery/Failback
Should a NAS share or VTL become unavailable on a source DL, two methods are available to access the
data either at the target system (recovery) or by replicating the share/VTL to the source DL (failback).
In order for the replicated NAS share or VTL to be accessed by a secondary server on the target DL, a
recovery must be initiated. When a recovery on the target DL is performed, the NAS shares or virtual tape
libraries appear on the target DL. In order for a virtual tape library to be accessed by a secondary server on
the target side (visible to the SAN client ports), you will need to enter a name for the library, a virtual tape
drive model number, and the number of drives.
To fail back to the source DL, delete the original virtual tape library on the source DL first. If it is not
deleted, the NetBackup server may end up seeing the same barcodes twice. Perform a failback on the target
DL, and then perform a recovery on the source DL.
Conclusion
The processes and configuration recommendations described in this white paper are intended to assist you
in maximizing the performance and usage of the DL in the majority of NetBackup backup environments.
Since no two backup environments are exactly the same, it may be necessary to vary individual settings to
meet each specific environments requirements and goals.

References
EMC DL1500 and DL3000 - Best Practices Planning white paper
EMC DL1500 and DL3000 Version 1.1 New Features and Functions A Detailed Review white paper
EMC DL1500 and DL3000 Replication - Best Practices Planning white paper
EMC DL1500 and DL3000 Copying to Physical Tape Best Practices Planning white paper
EMC DL1500 and DL3000 with Veritas NetBackup OpenStorage (OST) Best Practices Planning
white paper
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 41



Appendix: Using replication with NetBackup
NetBackup can be configured to work collaboratively with replicated NAS shares. Recommendations for
configuring the DL systems as well as NetBackup are outlined in the sections DL setup and NetBackup
setup, respectively. It is important to note, however, that no scripting is needed for the replication process
for the DL in VTL mode, because cartridge-based replication of a tape volume occurs automatically when
it is dismounted on the source DL.
DL setup
The source and target DLs must be correctly configured for replication for this script to work.
Target DL is enabled to accept replication from the source DL.
Source DL is enabled to replicate to the target DL.
Source NAS share is created with deduplication enabled.
Target DL is configured with a NAS share with deduplication enabled and having the same name as
the source share.
Target NAS share must be configured as a directory/file-based target, with a sync ID the same as the
share name, and access must be unlocked.
Source NAS share must be configured for directory/file-based replication and with a sync ID the same
as the share name.
Do not configure replicate daily
Test that the share contents can be replicated between the two DL systems by performing a synchronization
on that share through the source DLs Console Manager (Data Services > Replication > Source Role >
NAS). Make sure this works before continuing with the next steps.
NetBackup setup
Configure NetBackup as follows:
Mount the source share on the media server.
Configure the server on which the replication script will run with SSH authentication.
Copy the bpend_notify script and modify it to include the name of the source DL and the share to
replicate.
Place the script in the NetBackup bin directory.
Authentication setup
The server the replication script runs upon must have SSH configured to log in to the (source) DL, from the
command line and without a password prompt. The script will rely on ssh to send the DL the commands to
replicate. Using the SSH client programs password authentication mechanism is not only insecure, but
difficult to do via a script. As a best practice, use of public key authentication is preferred. With public key
authentication, you can connect securely to the DL from the host server on which the script is run without
having to enter a password.
For Windows servers, you may need to use cygwin for ssh communication and openssh (a package
available from cygwin for key generation). If you do not have cygwin, you can obtain it from
http://www.cygwin.com. It is not necessary to install an ssh application on Linux hosts.
Create the keys
This procedure takes you through the steps to create and copy ssh keys from the server from which you will
run the post backup script for replication to the DL server.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 42



For Windows servers only
Perform the following steps on the host server from which you will be running the post backup script:
1. Open a command prompt and type the following:
c:\cygwin\bin\ssh-keygen.exe -t rsa
2. You will be prompted to enter a passphrase. Leave this blank.
3. Your public key will be saved as id_rsa.pub on the Windows server.
For Linux servers only
1. Log in as root.
2. Enter the following at the command prompt to generate the public and private keys:
ssh-keygen -t rsa
3. Elect to put the keys into the default directory.
4. Press Return when prompted for a passphrase.
5. Go to the default directory containing the generated keys and verify that the id_rsa.pub key exists.
Install the public key on the DL
1. Establish an ssh session with the source DL, logging in as cliadmin.
2. Append the id_rsa.pub key to the authorized_keys file in the cliadmin account on the source DL.
Test the keys
1. From a bash shell, test that the public key works by trying to ssh into the DL from your server without
the password. This may prompt you to trust the host's credential, but not as for a password or a
passphrase. For example:
$ ssh $DL -l cliadmin hostname
2. Run the remote hostname once more to confirm you get no prompts at all.
$ ssh $DL -l cliadmin hostname

If this does not work, you'll need to fix it before you can run the script.
NetBackup post-backup script example
The bpend_notify (bpend_notify.bat for Windows clients) can be modified to drive DL directory/file-level
replication of a NAS share from a local (source) DL to a remote one, ensuring consistency of the data, and
waiting for the replication to finish before reporting success or failure. It will not synchronize the
NetBackup catalog or update the catalog to know about the copy.
When used as is, this script modification will apply to all backups performed to the same mountpoint or
share. If, however, you want to replicate different mountpoint/shares for different backups, you will need to
rename the script to bpend_notify.policyname (bpend_notify.policyname.bat for Windows clients) where
policyname is the name of the NetBackup policy for the backup. You can also refine the replication further
by naming the script bpend_notify.policyname.schedulename (bpend_notify.policyname.schedulename.bat
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 43



for Windows clients) if, for example, the backup uses a different mounpoint/share for full backups as
compared with daily backups.
To use this script:
1. For UNIX clients, place a copy of bpend_notify in /usr/openv/netbackup/bin on the NetBackup server
on which the script will be run.

For Windows clients, place a copy of bpend_notify.bat in <install_path>\NetBackup\bin on the
NetBackup server on which the script will be run.
The bpend_notify script can be found in the "goodies" folder or subdirectory below the bin folder
ordirectory.
2. If desired, rename the bpend_notify script in the bin folder or directory to include the policy name
and/or schedule.
3. Edit the script to add a line that executes the ssh command and to cause the synchronization of the
backup mountpoint/share on the local DL system to the remote DL system.
This Windows example uses the ssh package included in cygwin. Note that you must add "@" to the
beginning of the command line added to the NetBackup script. If you are using another ssh package,
ssh execution may require different syntax.

C:\cygwin\bin\ssh.exe -n source_DL -l cliadmin syscli --sync nas --name share_name

For UNIX, the command line is:
ssh -n source_DL -l cliadmin syscli --sync nas --name share_name

Where source_DL is the name of the source DL system that contains the NAS share and share_name is
the name of that share.
For example, the following line will be added to the bpend_notify.bat script:
@C:\cygwin\bin\ssh.exe -n cosmowanda -l cliadmin syscli --sync nas --name wayne

Hint: First test the command line you entered into the script to make sure it works before running the script. Verify
that no errors are reported by the command and that the source DL says that the synchronization occurred. After
modifying your script as described, be sure to verify (after a backup job runs) that the synchronization did indeed
take place.

===========================SCRIPT FROM NBU AND MODIFIED TO ADD A SINGLE
LINE=============================


@REM $Id: bpend_notify.bat,v 1.3 2006/08/01 20:46:43 $
@REM ***************************************************************************
@REM * $VRTScprght: Copyright 1993 - 2007 Symantec Corporation, All Rights Reserved $ *
@REM ***************************************************************************
@REM ecpyrght
@REM
@REM bpend_notify.bat
@REM
@REM This script is called by NetBackup when bpbkar is finished doing a
@REM backup on the client. It is also called after backing up the files
@REM for a user directed archive, but before the files are deleted.
@REM
@REM This script receives 6 parameters:
@REM %1 = CLIENT_NAME
@REM %2 = POLICY_NAME
@REM %3 = SCHEDULE_NAME
@REM %4 = SCHEDULE_TYPE, one of the following: FULL, INCR, CINC, UBAK, UARC
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 44



@REM %5 = Status of backup
@REM %6 = RESULT_FILE
@REM
@REM The script must reside in in the same directory as the rest of the NetBackup
@REM client binaries (install_path\netbackup\bin\bpend_notify.bat).
@REM It must also be executable by the root user.
@REM Should exit with 0 upon successful completion
@REM
@REM Naming conventions:
@REM There are three different versions of names that the scripts can use.
@REM The start notify script may use one version and the end notify script may use
@REM another, or they can both use the same version.
@REM
@REM Substitute "policy" with the NetBackup policy being used and "sched" with the
@REM schedule name. "bpend" can be substituted with "bpstart".
@REM bpend_notify.policy.sched.bat
@REM bpend_notify.policy.bat
@REM bpend_notify.bat
@REM
@REM Result files:
@REM The result file names will be dependant on the script file names.
@REM Example:
@REM Script name: Result file name:
@REM bpstart_notify.policyA.schedB.bat BPSTART_RES.policyA.schedB
@REM bpstart_notify.policyB.bat BPSTART_RES.policyB
@REM bpend_notify.bat BPEND_RES
@REM bpend_notify.policyC.bat BPEND_RES.policyC
@REM
@REM CAUTION: Writing anything to stdout or stderr will cause backup problems.
@REM Output should be redirected to the results files.
@REM
@REM --------------------------------------------------------------------
@REM main script starts here
@REM This is a simple script that records what kind of backup was done along
@REM with other relevent information (Client name, policy name, etc) and
@REM appends the information to the results file
@REM --------------------------------------------------------------------
@C:\cygwin\bin\ssh.exe -n source_DL -l cliadmin syscli --sync nas --name share_name
@if "%4" == "FULL" goto FULL
@if "%4" == "CINC" goto CINC
@if "%4" == "" goto FAIL
@REM print a generic message since backup is neither full, nor cumulative incremental
@echo backup/restore finished on %1 using policy %2 with schedule %3 and status %5, bpres
= %6 >> bin\BP_RES.txt
@echo 0 >> %6
@GOTO :EOF
@REM exit 0
:FULL
@echo full backup finished on %1 using policy %2 with schedule %3 and status %5, bpres =
%6 >> bin\BP_RES.txt
@echo 0 >> %6
@GOTO :EOF
@REM exit 0
:CINC
@echo cumulative incremental backup finished on %1 using policy %2 with schedule %3 and
status %5, bpres = %6 >> bin\BP_RES.txt
@echo 0 >> %6
@GOTO :EOF
@REM exit 0
:FAIL
@REM no schedule type information was sent. A failure has occured. Write status 1 to
results files.
@echo 1 >> %6
@GOTO :EOF
@REM exit 0

EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 45



Recovery from a replicated NAS share
When the target DL is configured with a NAS share, NetBackup may be able to recover data directly from
the replicated DL. This process assumes that the DL systems have been configured according to the DL
setup section on page 42.
1. Pause replication on the source DL. Even though the source DL may be unavailable the state of
replication may still be active.
2. Unmount the share on the source DL.
3. Mount the share on the target DL. NetBackup now recognizes the replicated data and can manage
recovery from the target share.
EMC DL1500 and DL3000 with Veritas NetBackup
Best Practices Planning 46

Вам также может понравиться