Backup Exec 20.2 Administrator's Guide
- Introducing Backup Exec
- Installation
- Methods for installing the Agent for Windows
- Using a command prompt to install the Agent for Windows on a remote computer
- Using a command script to install the Agent for Windows
- Installing the Remote Administrator
- Installing Backup Exec using the command line (silent mode)
- Backup Exec license contract information
- About upgrading to Backup Exec
- Getting Started
- Backups
- Backing up data
- Restores
- How Backup Exec catalogs work
- Job management and monitoring
- Alerts and notifications
- Enabling active alerts and alert history to display on the Home tab
- Adding a recipient group for alert notifications
- Sending a notification when a job completes
- SNMP traps for Backup Exec alerts
- Disk-based and network-based storage
- Configuring disk storage
- Configuring disk cartridge storage
- Backup sets
- Cloud-based storage devices
- Amazon S3 cloud-based storage
- Google cloud-based storage
- Microsoft Azure cloud-based storage
- Private cloud-based storage
- About S3-Compatible Cloud Storage
- About the Backup Exec™ CloudConnect Optimizer
- Legacy backup-to-disk folders
- Legacy backup-to-disk folders
- Legacy backup-to-disk folders
- Tape storage
- Robotic libraries in Backup Exec
- Creating robotic library partitions
- Managing tapes
- Creating media sets for tapes
- Labeling tape media
- Default media vaults
- Storage device pools
- Storage operations
- Conversion to virtual machines
- Configuration and settings
- Using Backup Exec with firewalls
- Deleting DBA-initiated job templates
- Backup Exec logon accounts
- Reports
- Creating a custom report
- List of Backup Exec standard reports
- Instant Cloud Recovery
- Preconfigurations to be completed in the Azure portal
- Troubleshooting Backup Exec
- Troubleshooting failed components in the SAN
- Generating a diagnostic file for troubleshooting Backup Exec
- Using Backup Exec in cluster environments
- Configurations for Backup Exec and Microsoft Cluster Servers
- Disaster recovery of a cluster
- Simplified Disaster Recovery
- Setting or changing the alternate location for the disaster recovery information file
- Creating a Simplified Disaster Recovery disk image
- Preparing to recover from a disaster by using Simplified Disaster Recovery
- Recovering a computer with Simplified Disaster Recovery
- Performing manual disaster recovery
- Integration with Veritas™ Information Map
- Appendix A. Backup Exec Agent for Windows
- About the Backup Exec Agent Utility for Windows
- Appendix B. Backup Exec Deduplication Feature
- Creating or importing deduplication disk storage
- Selecting storage devices for direct access sharing
- Appendix C. Backup Exec Agent for VMware
- About establishing trust for a vCenter/ESX(i) server
- Backing up VMware virtual machines
- About instant recovery of a VMware virtual machine
- About Recovery Ready for VMware virtual machines
- Appendix D. Backup Exec Agent for Microsoft Hyper-V
- Backing up Microsoft Hyper-V virtual machines
- About instant recovery of a Hyper-V virtual machine
- About Recovery Ready for Hyper-V virtual machines
- Appendix E. Backup Exec Agent for Microsoft SQL Server
- Backing up SQL databases and transaction logs
- Restoring SQL databases and transaction logs
- Disaster recovery of a SQL Server
- Appendix F. Backup Exec Agent for Microsoft Exchange Server
- Backing up Exchange data
- Appendix G. Backup Exec Agent for Microsoft SharePoint
- Backing up Microsoft SharePoint data
- Appendix H. Backup Exec Agent for Oracle on Windows or Linux Servers
- Configuring the Oracle Agent on Windows computers and Linux servers
- Configuring an Oracle instance on Windows computers
- Viewing an Oracle instance on Windows computers
- About authentication credentials on the Backup Exec server
- About backing up Oracle databases
- About restoring Oracle resources
- Appendix I. Backup Exec Agent for Enterprise Vault
- About backup methods for Enterprise Vault backup jobs
- Restoring Enterprise Vault
- About the Backup Exec Migrator for Enterprise Vault
- Configuring the Backup Exec Migrator
- About retrieving migrated Enterprise Vault data
- About the Partition Recovery Utility
- Appendix J. Backup Exec Agent for Microsoft Active Directory
- Appendix K. Backup Exec Central Admin Server Feature
- About installing the Central Admin Server feature
- What happens when CAS communication thresholds are reached
- About job delegation in CAS
- How to use Backup Exec server pools in CAS
- How centralized restore works in CAS
- Appendix L. Backup Exec Advanced Disk-based Backup Feature
- Appendix M. Backup Exec NDMP Feature
- About restoring and redirecting restore data for NDMP servers
- Viewing the properties of an NDMP server
- Viewing storage properties for an NDMP server
- Appendix N. Backup Exec Agent for Linux
- About installing the Agent for Linux
- About establishing trust for a remote Linux computer in the Backup Exec list of servers
- Editing configuration options for Linux computers
- About backing up a Linux computer by using the Agent for Linux
- About restoring data to Linux computers
- Editing the default backup job options for Linux computers
- Uninstalling the Agent for Linux
- Appendix O. Backup Exec Remote Media Agent for Linux
- About installing the Remote Media Agent for Linux
- About establishing trust for a Remote Media Agent for Linux computer in the Backup Exec list of servers
- About the Backup Exec operators (beoper) group for the Remote Media Agent for Linux
- About adding a Linux server as a Remote Media Agent for Linux
- Editing properties for the Remote Media Agent for Linux
- Creating a simulated tape library
- Viewing simulated tape libraries properties
- Appendix P. Accessibility and Backup Exec
- About keyboard shortcuts in Backup Exec
- Backup and Restore tab keyboard shortcuts
- Storage tab keyboard shortcuts
Backing up SQL databases and transaction logs
Backup Exec includes three methods for backing up databases: Full, Differential, and Full Copy-only. The full method backs up the entire database including all system tables. The differential method backs up only the changes made to the database since the last full backup. The copy method works in the same manner as the full method, except that it does not affect future differential or log backups.
A differential backup is smaller and faster than a full backup, so differential backups can be run more often than full backups. Because differential backups allow the restore of a system only to the point that the differential backup was created, you should also create multiple log backups between the differential backups. Using transaction log backups allows you to recover the database to the exact point of failure.
Consider using differential backups when only a relatively small amount of data changes between full backups, or if the same data changes often. Differential backups may also work well in your environment if you are using the simple recovery model and need backups more often, but cannot spare the time to do frequent full backups. If you are using the full or bulk-logged recovery models, you can use differential backups to decrease the time it takes to roll forward log backups when restoring a database.
If you want to run database backups only, instead of a mix of database and log backups, use the simple recovery model for the database so that the transaction log is automatically truncated when a checkpoint occurs in the database. This helps prevent transaction logs from becoming full since with other recovery models the logs are not cleared after a database backup.
With the simple recovery model, copies of the transactions are not stored in the log file, which prevents transaction log backups from being run.
If you do not run transaction log backups, you can recover the database to the point of the last backup, but you cannot restore the database to the point of failure or to a specific point in time.
System databases can only be backed up with the full method; you cannot use the log or differential methods to back up the master database.
Note:
You cannot back up databases to storage that is attached to a computer on which the Remote Media Agent for Linux Servers is installed.
The SQL Agent supports a mirrored SQL database configuration, although Microsoft places the following limitations on the mirroring of SQL databases:
You cannot back up or restore a mirrored SQL database. If you attempt to back up or restore a mirrored database, the backup job or restore job fails.
You cannot restore the primary SQL database while it is configured in a mirrored configuration. To restore the primary SQL database, you must stop database mirroring of the primary database.
You can back up a primary SQL database and its transaction logs only if the backup job does not leave the database in a non-recovered state.
You can set backup job default options for all SQL backup jobs. Each time you create a backup job, the job uses the default options unless you change the options for that particular job.
If you select a volume that contains SQL data for backup, the SQL Agent determines which SQL data should not be included in a volume-level backup. For example, .MDF and .LDF files should not be part of the backup because they are opened for exclusive use by the SQL system. These files will be automatically excluded for backup by a feature called Active File Exclusion. If this exclusion did not happen during a non-snapshot backup, these files would appear as in use - skipped. If this exclusion did not happen during a snapshot backup, the files would be backed up in a possible inconsistent state, which could create restore issues.
While it is not recommended, if you want to include SQL data in a volume-level backup, you must first dismount the database that you want to back up. Then, run the backup job.
You may need to manually add resource containers for SQL clusters before you can back up the databases.
To add resource containers, install the Agent for Windows on the cluster physical nodes. If the resource container for the virtual SQL server is not automatically detected, use the Add Server wizard to add the virtual resource container for the SQL virtual cluster node. When you run the Add Server wizard, uncheck the option because it is already installed on the physical node. Then, make your backup selections from the virtual resource container that you added.
When you run log backups, you should use Backup Exec exclusively to perform log transaction backups.
Backup Exec provides the Log and Log No Truncate methods for backing up transaction logs.
Use the Log No Truncate method only when the database is corrupted or if database files are missing. This method backs up the transactions that you may not be able to access otherwise when the database is in this state. You can then use this transaction log backup along with the last database backup and any previous transaction log backups to restore the database to the point at which it failed. However, any uncommitted transactions are rolled back. The Log No Truncate method does not remove committed transactions after the log is backed up.
To use the Log No Truncate backup to restore a database, you should also have a database backup that was created before the Log No Truncate backup. The transaction log contains only the log files that are used in the restore process, which alone are not sufficient to restore a complete database. You must have at least one database backup and a log backup of the database to restore the database.
Caution:
Do not run a log backup using either method if the SQL database uses the simple recovery model. With the simple recovery model, you can recover data only up to the most recent full or differential backup. If you run a log backup on a database using the simple recovery completion state, the backup completes with exceptions.
To check the database properties, from the Database management tools on the SQL Server, right-click the database, click
, click the tab, and then view the configuration settings.To back up SQL databases and transaction logs
- On the Backup and Restore tab, right-click a SQL Server, and then right-click the selection.
To select multiple servers, Shift + click or Ctrl + click the server names, and then right-click one of the selected servers.
- Select Backup, and then select the type of backup that you want to perform.
- On the Backup Definition Properties dialog box, in the Selections box, click Edit.
- On the Backup Selections dialog box, check the check boxes for the resources that you want to back up and uncheck the check boxes for the resources that you do not want to back up.
Note:
You can select the SQL databases to back up on the Browse tab. In the right pane of the Backup Selections dialog box, you can view the Name, Size, Type, Modified Time, and Attributes for the selection. The Attributes provide the status of the database, so if there are any problems you can resolve them before you run the backup job. You can also include or exclude specific files or specific types of files using the Selection Details tab.
- Click OK.
- On the Backup Definition Properties dialog box, in the Backup box, click Edit.
- On the Backup Options dialog box, select the schedule for this job.
- On the Backup Options dialog box, select the storage device for this job.
- On the Backup Options dialog box, in the left pane, select Microsoft SQL.
- Set any of the following options for this job:
Backup method
Select one of the following backup methods that you want to use for this job:
Full - Back up databases
This option backs up the entire database. This option is selected by default.
Full Copy - Back up databases (copy)
This option backs up the entire database without affecting future differential or log backups.
Unlike the Full backup method, the Full Copy backup method does not reset the SQL differential baseline that is used to indicate the database blocks that have changed since the last full backup.
After making a full backup, you can use the Full Copy backup method to make a copy of a SQL database without affecting the baseline backup set required to run future differential backups.
Backup method
Select one of the following SQL-specific backup methods that you want to use for this job:
Full - Back up databases
This option backs up the entire database. This option is selected by default.
Full Copy - Back up databases (copy)
This option backs up the entire database without affecting future differential or log backups.
Unlike the Full backup method, the Full Copy backup method does not reset the SQL differential baseline that is used to indicate the database blocks that have changed since the last full backup.
After making a full backup, you can use the Full Copy backup method to make a copy of a SQL database without affecting the baseline backup set that is required to run future differential backups.
Automatic - Backup up transaction log if enabled and then back up database changes since the last full or incremental
This option lets you back up the entire SQL instance even though some databases may not support log backups. All of the databases are backed up using the Incremental (block level) backup method. In addition, the databases that support log backups are backed up using the Log backup method.
Note:
If snapshot is not enabled, an Incremental (block level) backup method cannot be performed and the Differential backup method is used.
Log - Back up and truncate transaction log
This option backs up only the data contained in the transaction log; it does not back up database data. After the transaction log is backed up, committed transactions are removed (truncated).
If the databases are configured for the SQL Server simple recovery model, log backups are not supported. To change the recovery model, use the SQL administration tools to set the recovery model to Full. You should run a new full backup if you change the recovery mode before a log backup is run.
Alternatively, you can run full backups only, or run full and differential backups of the SQL databases.
See Configuring Backup Exec to run a consistency check before every SQL backup.
Log No Truncate - Back up without truncating transaction log
This option backs up the database when it is corrupt or database files are missing. Since the Log No Truncate backup method does not access the database, you can still back up the transactions that you may not be able to access otherwise when the database is in this state. You can then use this transaction log backup along with the database backup and any previous transaction log backups to restore the database to the point at which it failed; however, any uncommitted transactions are rolled back. The Log No Truncate backup method does not remove committed transactions after the log is backed up.
Differential - Backup up database changes since the last full
This option backs up only the changes made to the database or filegroup since the last full backup. Because differential backups allow the restore of a system only to the point in time that the differential backup was created, you should also create multiple log backups between the differential backups.
Differential (block-level) - Back up database changes since the last full - use with convert to virtual machine job
This option backs up all of the blocks of data and logs that have been created or modified since the last full backup.
Incremental (block-level) - Back up database changes since the last full or incremental - use with convert to virtual machine job
This option backs up all of the blocks of data and logs that have been created or modified since the last full or incremental backup.
Database Snapshot - Read-only point-in-time copy of databases
This option creates a read only, point-in-time copy of another database.
Note:
SQL differential or incremental backups are only supported for conversion to virtual when you use the Automatic, Differential (block-level), or Incremental (block-level) backup methods.
Additionally, Backup Exec runs a full backup when you select the Automatic or Log backup methods if a full backup was not previously run on the database. A full backup also runs for one of the following conditions:
A new database is added or restored.
Backup Exec did not run the last full backup.
Only Full Copy and Incremental backups were run on the database instead of Full backups.
Consistency check before backup
Select one of the following consistency checks to run before a backup:
None.
This option does not run a consistency check before a backup. It is recommended that you always run a consistency check either before or after the backup.
Full check, excluding indexes.
This option excludes indexes from the consistency check. If indexes are not checked, the consistency check runs significantly faster but is not as thorough.
Full check, including indexes.
This option includes indexes in the consistency check. Any errors are logged.
Physical check only.
This option performs a low-overhead check of the physical consistency of the database. This option only checks the integrity of the physical structure of the page. This option is selected by default.
Continue with backup if consistency check fails
Choose if you want to continue with the backup operation even if the consistency check fails. You may want to continue with the backup when the consistency check fails if you think that a backup of the database in its current state is better than no backup at all, or if you are backing up a very large database with only a small problem in a table.
Select the consistency check to run after a backup. Because database transactions can occur during or after the consistency check, but before the backup runs, consider running a consistency check after the backup to ensure that the data was consistent at the time of the backup
The following options are available:
None.
This option does not run a consistency check after a backup. It is recommended that you always run a consistency check after the backup. This option is selected by default.
Full check, excluding indexes.
This option excludes indexes from the consistency check. If indexes are not checked, the consistency check runs significantly faster but is not as thorough.
Full check, including indexes.
This option includes indexes in the consistency check. Any errors are logged.
Physical check only.
This option performs a low overhead check of the physical consistency of the database. This option only checks the integrity of the physical structure of the page. This option is selected by default.
Use checksums on backup (SQL 2005 or later)
Choose to add the checksums to the SQL database data being backed up by Backup Exec. Adding checksums to the data being backed up is required if you want to use the restore option Run verify only and do not restore data. Use this option and the Run verify only and do not restore data option to ensure that you restore from a verified SQL backup during a restore of the SQL database.
Create on-disk copies of SQL backups to be placed on the SQL server where the database is located
Choose to create an on-disk copy of the SQL database that you want to back up. This option lets you simultaneously back up a SQL database to storage media while also writing a copy of the database to a disk path you specify in the Save to path option.
This option gives IT administrators the ability to back up SQL databases while also providing database administrators with copies of the database on disk, which can be used for such things as tests and restores.
Note:
This option does not support snapshot technology.
Save to path
Specify a path in which to save on-disk copies of SQL backups.
SQL Server 2008 Enterprise Edition software compression
Select a compression setting that you want to use for this backup job:
None.
Do not use compression.
Compress.
Use SQL Server 2008 or later compression if it is supported by the SQL Server instance that is installed.
SQL compresses the data on the computer on which SQL Server 2008 Enterprise Edition or later is installed. Therefore, faster SQL 2008 or later backups should occur if you use SQL compression.
You can find a list of compatible operating systems, platforms, applications, and supported service packs in the Backup Exec Software Compatibility List.
It is recommended that you do not use SQL 2008 or later software compression in a backup job that also uses Backup Exec-initiated software compression. Minimal benefits are gained when you enable Backup Exec compression. In fact, in jobs where both compression schemes are used, backup times may increase.
SQL 2008 or later software compression is not used if a backup job that includes SQL 2008 or later data uses Advanced Open File options.
Note:
You cannot use this option for backup jobs that deduplicate data.
Specifies one of the following methods for one-time backups:
Full - Back up databases
This option backs up the entire database. This option is selected by default.
Full Copy - Back up databases (copy)
This option backs up the entire database without affecting future differential or log backups.
Unlike the Full backup method, the Full Copy backup method does not reset the SQL differential baseline that is used to indicate the database blocks that have changed since the last full backup.
After making a full backup, you can use the Full Copy backup method to make a copy of a SQL database without affecting the baseline backup set required to run future differential backups.
Database Snapshot - Read-only, point-in-time copy of another database
This option creates a read only, point-in-time copy of another database.
Log No Truncate - Back up without truncating transaction log
This option backs up the database when it is corrupt or when database files are missing. Since the Log No Truncate backup method does not access the database, you can still back up transactions that you may not be able to access otherwise when the database is in this state. You can then use this transaction log backup along with the database backup and any previous transaction log backups to restore the database to the point at which it failed; however, any uncommitted transactions are rolled back. The Log No Truncate backup method does not remove committed transactions after the log is backed up.
Log - Back up and truncate transaction log
This option backs up only the data contained in the transaction log; it does not back up database data. After the transaction log is backed up, committed transactions are removed (truncated).
If the databases are configured for the SQL Server simple recovery model, log backups are not supported. To change the recovery model, use the SQL administration tools to set the recovery model to Full. You should run a new full backup if you change the recovery mode before a log backup is run.
Alternatively, you can run full backups only, or run full and differential backups of the SQL databases.
Warning:
Data lifecycle management (DLM) deletes all expired backup sets that are created by a one-time backup job. DLM does not keep the last backup set after the retention date expires if the backup set is from a one-time backup. To prevent the backup sets from being automatically deleted, you can manually retain specific backup sets or you can change the expiration date of the backup set.
See How data lifecycle management (DLM) deletes expired backup sets on disk-based storage.
See Configuring Backup Exec to run a consistency check before every SQL backup.
- On the Backup Options dialog box, click any of the optional settings in the left pane that you want to set for this job.
- Click OK.
- On the Backup Definition Properties dialog box, click OK.
See Adding a stage to a backup definition.