Best practices for using Backup Exec 2012 with server clusters

• To prevent possible loss of data in failover situations, Symantec recommends that you use the backup method Incremental - Using modified time when you configure backup jobs. Do not use the backup method, Incremental - Using archive bit (reset archive bit).

When you apply Backup Exec patches to clustered Backup Exec media servers or a central administration server, Symantec recommends the following to prevent possible data loss:

• Use the Microsoft Cluster Administrator to set each of the clustered Backup Exec services so that they do not automatically restart after a failure occurs. By doing that, you prevent the cluster from changing nodes in the event of a failure.
  After you finish applying the patches, you should reset each of the clustered Backup Exec services so that they restart after a failure occurs.

Best practices for Backup Exec 2012 reports

Backup Exec includes standard reports that show detailed information about your system. You can also create reports that contain information to meet the specific requirements of your organization.

Reports can be viewed and printed in the following formats:

• PDF
• HTML
• XML
• Microsoft Excel (XLS)
• Comma Separated Value (CSV)

The following best practices can ensure smooth operations when you format or print Backup Exec reports:

• To properly format Backup Exec reports, you must configure a default printer in Windows even if you don't intend to print reports.
• To print reports in HTML, PDF, or Excel format, use the printer's landscape orientation.
• To create complex custom reports, you need a working knowledge of SQL and detailed information on Backup Exec's report database schema.

Best practices for Backup Exec 2012 and LiveUpdate

• Run LiveUpdate before and after each Backup Exec installation or upgrade.
• Schedule LiveUpdate to run when backup jobs are idle to optimize system performance.
• Use the Update feature on the Backup and Restore tab to update the Agent for Windows on remote computers with the same patches that were installed on the Backup Exec server. LiveUpdate does not update the Agent for Windows on remote computers.

Best practices for Backup Exec 2012 and Symantec Endpoint Protection

Install Symantec Endpoint Protection Manager on the Backup Exec server to enable integration features between Backup Exec and Symantec Endpoint Protection. If Internet Explorer's Trusted sites security level is set to High, you must add the following URL to the Internet Explorer Security tab as a trusted site:

http://securityresponse.symantec.com

Create special backup jobs for your most crucial data and configure them to run automatically when Symantec's ThreatCon level escalates. This strategy helps ensure that your vital data is safely backed up as soon as global threats are detected.

Consider the types of jobs that you want to run automatically and the potential impact they can have on your system resources. The ThreatCon level can be raised at any time without warning. If you configure large or resource-intensive jobs to run automatically, they may interfere with your normal business operations. You should also carefully consider the impact of setting Symantec Endpoint Protection integration as a global default for all new jobs. When the ThreatCon level is raised, all jobs with the default setting run automatically. If they are configured for integration with Symantec Endpoint Protection, even completed, nonrecurring jobs rerun automatically.

Ensure that you have Internet connectivity for the Backup Exec server on which Symantec Endpoint Protection is installed. The Backup Exec server must be connected to the Internet to update the ThreatCon level.

Click here for more information on ThreatCon

Best practices for Backup Exec 2012 Simplified Disaster Recovery

Create a custom SDR disk whenever you update the host bus adapter or network interface card hardware or software. This practice ensures that you have the latest hardware or software drivers that may be required for restore.

Use SDR to perform a test recovery of a non-production computer before a disaster occurs. You can use a virtual environment such as VMWare or Hyper-V for test recovery purposes. A test recovery lets you familiarize yourself with the SDR recovery process before it is needed.

To perform disaster recovery of a remote computer, you must purchase the Agent for Windows separately, and it must be running on the remote computer.

For disaster recovery purposes, consider the following:

• The number of installed hard disks must be the same size or larger than the original.
• The latest RAID, SCSI, or NIC (if remote) drivers are required.

SDR supports recovering computers that use the Unified Extensible Firmware Interface (UEFI) standard. However, backups of UEFI-based computers cannot be restored to standard BIOS-based computers.

Note:

UEFI computers use GPT-style disks. MBR-style disk data cannot be restored to GPT-style disk, and vice versa.

For computers that support both UEFI and BIOS firmware types, you must start the computer using UEFI firmware if you backed up the computer in that mode.

If you have OEM partitions such as Dell Utility partitions on the system, they are considered part of a computer's critical system components and are backed up and restored as such.

Ensure that Backup Exec Database maintenance runs after you configure new storage devices on your Backup Exec server but before you run an SDR-compatible backup job. This ensures that the Backup Exec Database contains the latest storage device configuration details, which can be restored as part of a SDR recovery. You can set the schedule to run a Backup Exec Database maintenance by enabling the option, Enable Backup Exec database maintenance, under Backup Exec Settings > Database Maintentance.

Best practices for Backup Exec 2012 data lifecycle management

• To get more disk space before data lifecycle management expires any backup sets, you can delete unwanted backup sets manually in Backup Exec. Do not use Windows Explorer or a Windows command prompt to delete backup files.

  Note:

  By default, the data lifecycle management process runs every four hours. Data lifecycle management also runs whenever the available disk space on the Backup Exec server is less than the low disk space thresholds that are set in the disk storage properties.

• To prevent data lifecycle management from expiring a backup set, you can manually retain a backup set. Backup Exec automatically retains all dependent backup sets as well. When you no longer want to retain a backup set, you must release it so that data lifecycle management can manage the retention period for it.
• When setting up the schedules for backups in a backup definition, avoid adding many incremental backups between full backups. The data lifecycle management process must search through each backup set to check dependencies; therefore, the more incrementals there are, the longer the DLM process takes.

Best practices for Backup Exec 2012 catalogs

• Do not delete or edit the files in BE_INSTALL\Catalogs\directory. The catalog files store the metadata for the backup sets.
• Back up the catalog files in BE_INSTALL\Catalogs\directory. Consider backing up the catalog files after you back up or perform maintenance on the Backup Exec Database.
  
  

The following recommendations are to help you choose the best catalog location to use in a Central Admin Server Option (CASO) environment:

• The distributed catalog location is the default location, and is efficient and suitable for a CASO environment that uses a wide area network (WAN). An example of this environment is if the central administration server is located in a cloud and the managed Backup Exec servers are on a local network.
• The centralized catalog location is best suited for use in a CASO environment that uses SAN-connected shared storage with a stable, high-bandwidth network between the central administration server and the managed Backup Exec servers. Use a centralized catalog location if the managed Backup Exec servers have minimal CPUs and disk space, and if the central administration server has significantly more CPUs and memory.
• The replicated catalog location is best suited for a CASO environment that has a stable, high-bandwidth network between the central administration server and the managed Backup Exec servers. A replicated catalog location can provide better performance through catalog redundancy since queries for catalog information are performed locally.