|
| Specifies one of the following consistency checks to run before a backup: None. This option does not run a consistency check before a backup. Symantec recommends that you always run a consistency check either before 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.
See About consistency checks for SQL
|
|
| Continues 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.
|
| Specifies 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. Symantec recommends 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.
|
|
| Adds 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 . Using this option, and the option, ensures that during a restore of the SQL database, you restore from a verified SQL backup.
|
|
| Creates an on-disk copy of the SQL database being backed 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 box.
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. |
|
|
| Displays a path in which to save on-disk copies of SQL backups.
|
| Specifies the following compression setting you want to use for this backup job: 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. If you back up remote SQL 2008 or later computers and you use SQL 2008 or later software compression, you must use the latest version of the Agent for Windows. You can find a list of compatible operating systems, platforms, and applications at the following URL: http://entsupport.symantec.com/umi/V-269-1 Symantec recommends that you do not use SQL 2008 or later software compression in a backup job that uses Backup Exec-initiated software compression. Minimal additional SQL 2008 or later compression 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 incremental backups: 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). Differential This option backs up only the changes that are made to the database since the last full backup. Because differential backups allows 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.
Note: | To back up SQL databases using a combination of log and differential backup methods, you must create two incremental backup jobs. For the first incremental backup job, select the Log option. For the second incremental backup job, select the Differential option. |
|
| Specifies one of the following methods for one-time backups: Full - Back up entire database This option backs up the entire database. This option is selected by default. See About backing up SQL databases. Full Copy-only (SQL 2005 or later) - Back up entire database This option backs up the entire database without affecting future differential or log backups. Unlike the Full backup method, the Full Copy-only 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-only backup method to make a copy of a SQL database without affecting the baseline backup set required to run future differential backups. Database Snapshot (SQL 2005 Enterprise Edition or later) - Read-only, point-in-time copy of another database This option creates a read only, point-in-time copy of another database. See About SQL 2005 or later database snapshots. Log No Truncate - Back up transaction log - no truncate This option backs up the database when it is corrupt or database files are missing. Since the Log No Truncate 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 method does not remove committed transactions after the log is backed up. 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 About consistency checks for SQL.
|
Thank you.