NetWorker Application Integration

Published   Read time 3 min(s) 53 sec(s)   (2438 views).  NetWorker  

VMWare Integration Can do guest or Image-based backup (VADP). When doing image backups, there is no need for LAN connectivity to the guests and is well suited to DR. File-level backup/recover is supported on Windows only. There is little impact on the host and guest.

When defining backup policies for guest-level backup, create backup groups with VMs across multiple ESX server to reduce load on individual hosts due to concurrent backup. Reduce full backup frequency to decrease I/O and network traffic and use modules for apps and database.

When using VADP, backup processing is offloaded to a proxy and can be done any time if done on another host. There is file-level recovery only for NTFS, and image recovery of a full VM from an incremental CBT is not possible.

Image-level backup requires a full backup after hardware change, OS patch or update, or driver updates. CBT can be used on ESX4.0+ with virtual hardware 7. One or more VADP proxy system is required (Windwos 2003-2008R2) and one or more vCenter server running a supported version (vSphere5-5.1, vCenter 4.0 or 4.1 managing ESXi 3.5-4.1 or VirtualCenter 2.5 with ESX 3.5). NetWorker 7.62 SP2 or newer on VADP procy and vCenter and have access to all LUNs.

VADP does not support IPv6, so disable it on Windows 2008. Set client parallelism on VADP proxy to max number of VM backups it will run concurrently, and keep the vCenter and VADP proxy as separate machines. Make your VADP proxy a storage node for any transport mode.

If using SAN transport mode, have 500MB RAM for each VM backup to run concurrently. Add proxies to increase throughput. Max concurrent backup per proxy is 50, unless using DDBoost, when it is 100.

If using Hotadd transport mode, at least 4 vCPU and 8 GB vRAM per virtual proxy. Client parallelism should not be set higher than 12, and no more than 5 virtual proxies on one standalone ESX server. Datastore for VADP proxy must have sufficient free BEFORE hotadd backup begins. Can not use hotadd backup for IDE virtual disks, you need to use ndb mode for these. Host all proxies on a dedicated ESXi server, and if VMs have more than 12 disks attached per VM, do NOT use hotadd mode.

Oracle Integration is possible with NetWorker.

RMAN channels are streams of data sent to a device or app like NetWorker. RMAN Multiplexing is not the same as tap multiplexing, but is rather multiplexing into a specific RMAN channel. FILESPERSET is the max number of files for a backup set, and MAXOPENFILES determines the max number of input files a backup can have open at one time.

Tune RMAN channels by using RMAN Multiplexing. Increase the stream count to match the target device count. Avoid tape multiplexing. Keep FILESPERSET <= MAXOPENFILES and increase RMAN multiplexing if there is little no striping of datafiles across disk storage and decrease if datafiles are striped across many disks.

Exclude things that don't change, but never exclude system tables (Master DB, control files) and reduce database sized by archiving databases. RMAN backup L1 will be differential by default unless specified to be cumulative. L1 diff backs up all data since last L0 or L1, cumulative backs up all since last L0 or full. On Oracle 10g or newer, CBT can be enabled to increase backup performance.

For Microsoft SQL databases, stripes are like RMAN channels in Oracle. NetWorker stores each stripe as a different save set.

NDMP is used for backing up NAS devices.

NDMP separates data path from control path to minimize network resource demand. NDMP file history is metadata sent to NetWorker server, and it is processed at the end of the backup job. This file history is read into a temp file and processed on disk in the form of a B-Tree. At the end of the backup the B-Tree on disk is processed and indexes are generated and committed. NDMP file history processing time is influenced by storage system factors such as RAID type, number of disks, cache size, etc.

During NDMP file history processing, /nsr/tmp is heavily used and the temp file isn't removed until after B-Tree file processing completes, meaning double the space is required during processing. Failover in a clustered NetWorker environment will interrupt index processing and index generation would be incomplete, so file level recovery will not be possible without restarting.

Space for the /nsr/tmp can be calculated as 2*(144+average file name length)*# of files. for a million files with an average filename length of 128 it would be 2*(144+128)*1,000,000 = 544 MB approximately. The location of the tmp directory can also be changed using NSR_NDMP_TMP_DIR set in the application information window on client config.