Run and schedule backups, synchronizations and custom commands

After a backup job is created, you can run it manually (ad hoc) at any time and schedule it to run on specific days of the week or month. See Run an ad-hoc backup and Schedule a backup.

To help you meet your recovery point objectives (RPOs), when Windows Agent 8.90 or later, Linux Agent 8.90 or later, AIX Agent 9.00 or vSphere Recovery Agent 9.11 is backing up data to a version 8.60 or later vault, you can schedule a backup job to run multiple times per day, as often as hourly. See Schedule a backup to run multiple times per day.

Note: Admin users can disable or enable all scheduled jobs for a computer or protected environment. See Disable or enable all scheduled backup jobs.

Beginning with Portal 9.30 and Windows Agent 9.30, Image and Local System backups can also be triggered by system events on supported Windows desktop operating systems. See Trigger backups when events occur on Windows desktop computers.

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 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.

  The following table describes deferral behavior for specific backup types:

  Backup type	Behavior
  System State	If the System State option is selected in a Windows backup job, the job cannot be deferred. If the agent tries to defer a job where System State data is being backed up, the backup fails.
  Image Plug-in	In an Image Plug-in job, once a volume has been completely backed up, a backup for that volume cannot be deferred. When an Image Plug-in job runs, the agent backs up changes in any volumes that have been completely backed up and then starts to back up any remaining volumes. The backup can be deferred for any volume that was not previously backed up completely. If an Image Plug-in backup job is deferred while a volume is being backed up, the backup for the volume is incomplete and data from the volume cannot be restored. However, you can restore volumes, and files and folders from volumes in the job that were completely backed up.
  SQL Server Plug-in	If a SQL Server Plug-in backup job is deferred while a database is being backed up, the backup for that database is incomplete and the database cannot be restored. However, you can restore databases that were completely backed up in the job before the job was deferred. If the backup is deferred while a SharePoint database is being backed up, the backup is incomplete and you cannot restore items from the database.
  Exchange Plug-in	Incremental backups for Exchange cannot be deferred, even if deferring is enabled. Deferring can be applied to full backups for Exchange.
  To SSI files	Backups to SSI files on disk cannot be deferred.
  Hyper-V Agent	Hyper-V Agent backups can only be deferred when they are run manually (ad hoc). You cannot defer scheduled Hyper-V backups.

• 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), be sure that only one tool is being used 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.

For computers with Windows or Linux Agent version 8.60 or later, or environments with vSphere Recovery Agent version 8.80 or later, you can specify whether scheduled backups should automatically retry if they do not run successfully. You can also specify how many times a scheduled backup should retry after a failed attempt, and specify the amount of time between retries. See Specify whether scheduled backups retry after a failure.

When you schedule a job to run, you can also set the compression level for the data. The compression level optimizes the amount of data stored vs. the backup speed. 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 a backup runs, you can view logs to check whether the backup completed successfully. See View a job’s 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 computer, runs a backup, and then restarts the services. See Schedule a custom command.