LAN free (including SAN backup) configurations with Backup Exec

[Colin_Weaver]

This blog is to outline some of the possible options to avoid backing up over the Corporate LAN in Backup Exec (BE). It does not discuss the specifics of configuration it just outlines the various options that might be available to show which environments might be more suitable to one option than another.

In practice members of technical support often see cases where customers ask something similar to the following:

How do I configure a LAN Free backup?
How do I backup over SAN?
How do I backup over Fibre-Channel?
How do I backup over iSCSI?
How do I backup across a backup or secondary network (including a Fiber Channel Network)?

These are all really the same question:

How do I backup my environment without the data transfer using bandwidth over my user/corporate network (LAN)?

Backup Exec Corporate LAN Free Possibilities

1. VMware SAN & Hot Add Transport mechanisms
2. Offhost Backup (ESO/ADBO)
3. NDMP Option
4. RMAL (Remote Media Agent for Linux)
5. Local Backup Exec Server/Media Server (or servers if you use SSO which is now part of ESO)
6. Backup / Secondary LAN

The following notes will try and explain when you might use each of these options but just for clarity a quick terminology reminder on the differences between a NAS and a SAN

NAS = Network Attached Storage

• Traditionally provides share level (CIFS) access to disk storage across a LAN
• Can be joined to a domain to manage security
• Stand Alone device with no ability to install 3rd party software

SAN = Storage Area Network

• SAN storage is traditionally directly attached to servers over Fiber-Channel and mounted as a local drive
• Can also be attached via iSCSI over LAN
• Security controlled by host server (the server that creates or owns the data in the SAN storage)
• Can be shared between servers across SAN switches for clustering etc
• 3rd party software can be implemented on the host servers (those that create or own the data in the SAN storage)

NOTE: Modern devices merge NAS and SAN technology. For example a NetApp Filer can provide shares on the network (as a NAS) and an iSCSI attachment to a LUN (to provide SAN storage)

---

VMware SAN & Hot-Add Transports
As the name implies these two options can only be used in VMware environments. It should also be noted that they both need an appropriate license package from VMware in addition to licenses that relate directly to Backup Exec (BE).

Key points about SAN transport:

• BE Virtual Agent, V-Ray Edition License or V-Ray Edition License Required, Application Agent License Optional (used for GRT)
• Backup Exec 2014 and older only support SAN Transport Backups, SAN Transport Restores are supported by Backup Exec 15 and newer, however are not recommended (by VMware and Veritas) as they can be slower than LAN based restores.
• Media Server MUST be physical to use SAN Transport
• The LUN (logical disk storage) containing the datastore must be presented to the media server as well as the ESXi Host
• The LUN must be visible as a volume in Windows Disk Manager or Diskpart utiltities (usually as Unknown Partition depending on operating system)
  • WARNING: The LUN should NOT be  partitioned, formatted or given a drive letter by the Disk management utility within the  Windows Operating System
    • If a customer does this they will corrupt their datastore and will need to speak to VMware for any possible fix
• If SAN Transport restore is either not supported or not required , then it is posible to configure SAN Read Only access between the Backup Exec Server and the LUN that contains the datastores
• Hardware Independent
• Both iSCSI and Fibre-Channel are supported
• Control connection is always over the LAN (BEREMOTE to ESXi Host/VCenter)

Key Points About Hot-Add Transport:

• BE Virtual Agent, V-Ray Edition or Capacity Edition License Required, Application Agent License Optional (used for GRT)
• Media Server MUST be virtual to use Hot-Add Transport
• The Media Server MUST be in the same virtual environment to use Hot-Add transport
• Process is similar to SAN transport except the mount snapshot for backup and data transfer is performed within the ESXi Host
• No visible attachment in Windows Disk manager
• Very limited ability to perform backups to tape (iSCSI VTL only)
• No supported ability for backup to USB or RDX (although in practice this configuration might work as an Alternative Configuration)

---

Off-Host Backups
The Off-host backup process makes use of transportable snapshot mechanisms provided by some disk storage vendors against supported devices. The disk storage would again need to be available across the SAN to both the server creating the data and the backup server.

• ESO License Required, Application Agent License requirement relates to data type
• Support for Off-Host backups is part of the Enterprise Server Option (ESO) but does not require a CASO setup
• In older Backup Exec versions it was part of Advanced Disk-based Backup Option (ADBO)
• Requires specific disk storage hardware (check the HCL*)
• Uses VSS Snapshots
• May require hardware provided support software (including hardware VSS providers) on both the source server and the media server (refer to specific vendors documentation for details)
• Only supports specific types of backup data (see BE Admin Guide)
  • Non-encrypted NTFS volumes
  • Microsoft SQL
  • Microsoft Exchange
• No support for Virtual (Hyper-V or VMware) Agents, although if off-host supported hardware is attached into a VM over iSCSI then in theory the backup of that volume would be supported by off-host backups but would conversely not be supported by the virtual agent backup.
• Control connection is always over the LAN (Job Engine to AWS on source server)

* Check the Hardware Compatibility List (VSS Providers for Offhost backup section) link for all recent BE versions that is available here http://www.veritas.com/docs/000017788

---

NDMP Option
The NDMP option makes use of the NDMP capabilities provided by some disk storage device vendors, in order to operate a directly attached tape library. As such local data held inside the disk storage can then be backed up directly to tape without being sent via the media server.

• NDMP Option License required, LEO License optional, ESO(SSO) license optional
• Requires supported NDMP Storage Device (see HCL)
• Control connection is always over LAN (Job Engine to NDMP Storage Device)
• LAN free is only possible with tape library attached to NDMP Storage Device
• LAN free is NOT possible if backing up to device attached only to the media server
• If required, a tape library can be shared with the media server (over SAN)
• If required, a tape library can be shared with other similar NDMP Storage Devices (over SAN)
• Backup selections (depending on NDMP device) may be limited to selecting complete volumes and not files or folders
• Incremental and Differential (Level) backups are not supported against LUNs - any change inside the LUN results in the complete LUN being backed up - for incremental and differential support, within a LUN, backup the data inside the LUN using a remote agent installed on the server that the LUN is connected to.
• No GRT capability for LUN or database content
  • If a VMware Datastore is inside the LUN, use VMware SAN Transport over iSCSI instead of NDMP Option
  • If an Exchange database is inside the LUN use remote agent or media server installed on the Exchange server instead of NDMP Option

Note: There is a 3-Way NDMP capability where a second filer from the same vendor can backup via the filer with the directly attached tape library, however this would send data over the LAN

---

RMAL Backups
The Remote Media Agent for Linux is a software implementation providing similar capability to that provided by the hardware vendors against using the NDMP Option. The host server, running a supported Linux version, can use a directly attached tape library and therefore backup Linux based data directly to the library without it going back to the media server.

• RMAL License Required, LEO License optional, ESO(SSO) license optional
• Requires supported Linux Operating System (see SCL)
• Control connection is always over LAN (Job Engine to RALUS/RMAL daemon)
• LAN free is just for backing up Linux data directly to tape
• If required Tape library can be shared with the media server (over SAN)

Note: There is a 3-Way RMAL capability where a second Linux host, running RALUS, can backup via an RMAL host with a directly attached tape library, however this would send data over the LAN

---

Local Backup Exec Server/Media Server Backups (including Shared Storage Option / SSO)
Making the server that owns the source data into a Backup Exec Server (originally known as a Media Server), results in LAN free backups

• Tape or disk storage can then be locally attached over SCSI, SAN or secondary LAN technologies
• Extra storage hardware (e.g. tape libraries) per source server required (especially if SSO is not implemented)
• Extra Backup Exec core server licenses will be needed
• Implementing SSO  allows a single library to be shared to all source servers, using SAN technology, thus reducing hardware costs
• For current BE versions this would require an ESO license with a CASO configuration using SSO settings. (older BE versions used a CASO or SSO license or both as appropriate)
• Application Agent licenses will be still needed (where appropriate)

Note: This is discussed against a secondary LAN technology in Option A of the solution in this article http://www.veritas.com/docs/000037728

---

Backup LAN
A cost effective way to transfer backup data outside of the corporate network is to add extra network cards. switches and cabling between the Backup Exec Server or Media Server and the servers to be backed up.  The performance may not be as good as SAN backup, however it will avoid bandwidth impacts on the corporate network. Whilst not officially tested, Client-side deduplication should work over a Backup LAN. Network interfaces that enable LAN Technology over Fiber Channel can also be used with this type of topology.

• Every Server involved in the backups needs two network cards
• A separate LAN switch (or possibly VLAN) along with associated cabling is required
• No extra Backup Exec software license are needed
• The Backup LAN must be on a different subnet
• All remote servers involved in the Backup LAN must name resolve the media server to its second IP address
• The Backup Exec Server(s) or Media server(s) must name resolve the remote servers in the backup LAN to their secondary IP addresses
• Clustered remote servers will need a secondary IP address within the cluster failover resource and name resolution for this resource name must also be correct on the media server and on each node of the cluster.
• VMware NBD backups have to use the network provided by the vCenter there is no ability to specify a secondary LAN, hence we cannot directly support VMware backups using a backup LAN.
• Hyper-V backups can use a secondary LAN if the Backup Exec server is separate from the Hyper-V hosts. Typically you would only give the hosts access to the Backup LAN, and therefore only have to correct the name resolution between Backup Exec server and the hosts. The GRT backup process may need to directly access the virtual machines over the LAN, but this is almost negligible traffic during backups as only metadata is collected. Also for most environments, GRT restores should be rare and it would be acceptable to perform the restore over the main LAN.

Note: This is discussed in Option B of the solution in this article http://www.veritas.com/docs/000037728

---

SUMMARY
The above notes should provide some reasons why one or another solution may not be appropriate for a given environment. To give some quick recommendations though

1. If VMware is involved use the SAN or HotAdd Transports even if NDMP Option or off-host supported hardware solution owns the data stores.
2. If Hyper-V is involved then the best option is to make the Hyper-V hosts into Backup Exec Servers (or Media Servers)
3. If NDMP option supported hardware is involved and a LUN configuration is not involved (NDMP device provides shares) then consider the NDMP option
4. If Off-host supported hardware is involved against either: standard file system, SQL or Exchange databases then consider using the off-host option.
5. If the data is held on a Linux host then consider the RMAL configuration
6. If the key data owning server can be made into a Backup Exec Server (or Media Server) than look at SSO (ESO) and a shared library
7. If there are no options using actual SAN technology, then consider using a secondary backup network.

NOTE: The information in this blog is only provided to ease understanding of the possible options, it does not guarantee that a specific method will be supported for a given configuration and as such anyone reading the blog will still need to do their own due diligence with regards to required licenses and the specifics of any required technical configurations.