h5714 dl3d with veritas bp wp

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


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


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


http://en.wikipedia.org/wiki/Computer_port_%28hardware%29

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 drive’s 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.


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 appliance’s 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 appliance’s 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 appliance’s 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.


• 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 DL’s 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.


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


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.


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%


@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;


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.


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.


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.


http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=--NULL--&internalId=0b01406680023902

http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=--NULL--&internalId=0b01406680023903

http://powerlink.emc.com/km/appmanager/km/secureDesktop?_nfpb=true&_pageLabel=--NULL--&internalId=0b014066801c09b1

• 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 DL’s 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 NetBackup’s “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 DL’s 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 DL’s 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.


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 technology’s 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.


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#wp1020899

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 vendor’s 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.




• 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 vendor’s 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 vendor’s 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.


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 Symantec’s 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.


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


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:




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


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]


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


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:




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.


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 server’s 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.


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:\.


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 NetBackup’s “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.


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 vendor’s 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_client=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 IBM’s 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


http://h20180.www2.hp.com/apps/Lookup?h_lang=en&h_cc=us&cc=us&h_page=hpcom&lang=en&h_client=S-A-R163-1&h_pagetype=s-002&h_query=LTO&submit.x=4&submit.y=5

http://h20180.www2.hp.com/apps/Lookup?h_lang=en&h_cc=us&cc=us&h_page=hpcom&lang=en&h_client=S-A-R163-1&h_pagetype=s-002&h_query=LTO&submit.x=4&submit.y=5

ftp://ftp.software.ibm.com/storage/devdrvr

http://www.storagetek.com/support/drivers

http://www.quantum.com/ServiceandSupport/SoftwareandDocumentationDownloads/Index

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. NetBackup’s 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 server’s 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 server’s 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.


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 DL’s 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.


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


http://support.microsoft.com/kb/842411/en-us

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 DL’s 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 DL’s 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 DL’s 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 NetBackup’s 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


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 Administrator’s 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 NetBackup’s 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 client’s 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.


ftp://exftpp.symantec.com/pub/support/products/NetBackup_Enterprise_Server/290205.pdf

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 Administrator’s 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 duplicate’s 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 DL’s 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.


http://seer.entsupport.symantec.com/docs/290233.htm




• 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


OpenStorage (OST) API support OpenStorage (OST) is a feature of Symantec’s 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 DL’s 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 DL’s 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 NetBackup’s 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.


http://powerlink.emc.com/

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.


• 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.


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 DL’s 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.


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 Manager’s 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.


• 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 customer’s 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


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 environment’s 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


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 DL’s 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 program’s 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.


http://www.cygwin.com/

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


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


@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


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.


h5714 dl3d with veritas bp wp

Documents