After a backup job is created, you can run it manually (ad-hoc) at any time and schedule it to run. Admin users can also disable or enable all scheduled jobs for a computer or protected environment.
When running or scheduling a backup, you can specify the following settings:
•Retention type. The retention type specifies the number of days a backup is kept on the vault, how many copies of a backup are stored online, and how long backup data is stored offline.
•Deferring. You can use deferring to prevent large backups from running at peak network times. When deferring is enabled, the backup job does not back up any new data after the specified amount of time and commits the safeset to the vault, even if some data in the job is not backed up. Changes to data that was previously backed up will be backed up, regardless of the specified amount of time.
When the job runs again, the Agent checks for changes in data that was previously backed up, backs up those changes, and then backs up the remaining data.
If a backup job is deferred while an item (e.g., file, database, volume, vSphere VMDK, or Hyper-V VM) is being backed up, the backup for that item is incomplete and data from the item cannot be restored. However, you can restore items that were completely backed up in the job before the job was deferred.
Note: Hyper-V Agent backups can only be deferred when they are run manually (ad hoc). You cannot defer scheduled Hyper-V backups.
Note: Backups to SSI files on disk cannot be deferred.
Note: Incremental backups for Exchange cannot be deferred, even if deferring is enabled. Deferring can be applied to full backups for Exchange.
•For a SQL Server Plug-in backup job, you can specify whether to back up the database, the transaction logs, or both. Frequent transaction log backups are recommended for databases with a high level of activity.
Note: After a transaction log backup, logs are marked for truncation. If you also back up databases using another tool (e.g., native SQL Server backup), use only one tool for truncating logs.
Note: Transaction logs can only be backed up for databases that use the full or bulk-logged recovery model.
•For an application-aware Image Plug-in job, you can specify whether to truncate SQL Server database transaction logs.
Note: If you also back up databases using another tool (e.g., native SQL Server backup), use only one tool for truncating logs.
•For an Exchange Plug-in backup job, you can specify whether to:
•Run a Full or Incremental backup. When the Full backup type is selected, the database files, checkpoint file and transaction logs are backed up. When the Incremental backup type is selected, the database files, checkpoint file and transaction logs are backed up in the first “seed” backup, but only the checkpoint file and transaction logs are backed up in subsequent runs. For more information, see Plan Full and Incremental Exchange backups.
•Validate Exchange data during the backup. When this option is selected, a utility checks the Exchange data during the backup. If data corruption is detected, the backup fails and the corruption is reported.
•When you schedule a job to run, you can also set the compression level for the data. The compression level optimizes the volume of data sent to the vault against the speed of processing. The default compression level is usually the optimal setting. For compression level descriptions, see Policy compression and log settings.
•When a backup job first runs, all data selected in the job is backed up to the vault. This initial backup is called a “seed” backup. In subsequent backups, only data that has changed is backed up to the vault, unless a reseed is required (e.g., after a job’s encryption password has changed). In a reseed, all data selected in a backup job is sent to the vault again, even though it has already been backed up.
•After running a backup, you can view logs to check whether the backup completed successfully. See View a jobs process logs and safeset information.
In some cases, you must synchronize a backup job before you run it or restore data from the job. When you synchronize a job, the Agent checks which safesets for the job are online and available for restore. See Synchronize a job.
You can also schedule custom commands to run on Windows and Linux computers. Custom commands are scripts that are saved on a computer where an Agent is installed and are scheduled to run through Portal. For example, you could schedule a custom command that shuts down services on the Agent computer, runs a backup, and then restarts the services. See Schedule a custom command.