SQL Backup Master Help

Online Documentation

Backup storage

These options are used to configure how database backup files are uploaded and stored.

General

  • Upload backups immediately - By default, all backup files are created in one step and subsequently uploaded. Enabling this option will cause backup files to be uploaded immediately after they are created (and optionally encrypted/compressed), thereby reducing temporary backup file storage requirements.
  • Create a folder for each database - Use this option to store backups of your databases in their own, separate folders.
  • Create a folder for each backup type (full, diff, log) - Similar to the above option, but creates separate subfolders for each backup type.

Automatic Cleanup

By default, SQL Backup Master will automatically delete superseded differential and transaction log backup files. This is done to conserve storage space.

Since each differential backup contains all the data changed since the last full backup, there's generally no need to keep previous differential backup files around.

Similarly, transaction log backups are generally only used to restore to some point after the latest full or differential backup.

The Always keep latest backup set option retains the most recent backups (for each database being backed up) during file cleanup operations, regardless of their age. For example, if you configure a backup destination to remove old backup files after 7 days, this option will retain the latest backup set even if it's older than that. Because disabling this option removes an important safety net, SQL Backup Master will ask you to confirm before turning it off.

Important: Be sure that your backup destination has sufficient storage space to accommodate whatever data retention options you choose.

Backup Chain Protection

Note: This section applies to SQL Backup Master v8.6 and later. Earlier releases evaluate each backup file individually, and the "keep latest" option retains the newest full, differential, and log files independently rather than as a set.

A differential backup can only be restored alongside the full backup it is based on, and transaction log backups require an unbroken sequence reaching back to a full or differential backup. Starting with v8.6, destination cleanup understands these backup chain relationships and will never delete a backup file that a newer, retained backup still depends on:

  • Chains are removed as a unit. When a destination's "delete backups after" period is configured, a full backup (and its dependent differential/log files) is only removed once every file in the chain has exceeded the configured age. Until then, over-age chain files are retained to keep newer backups restorable.
  • The latest backup set means a restorable set. The "Always keep latest backup set" option protects the newest full backup together with its latest differential and subsequent transaction logs — a set that can actually be restored. Immediately after a new full backup completes (before it has any dependent files), the previous backup set is also briefly retained.
  • Retention decisions are logged. Whenever files are kept beyond the configured clean-up period (or a whole chain expires and is removed together), the backup job log states exactly what was retained or removed, and why.
  • Destinations without full backups. If a destination is configured to receive only differential and/or log backups, chain relationships cannot be evaluated there, and the clean-up period applies to each file individually (as in earlier releases). The job log notes when this is the case.

As a result of chain protection, a destination may temporarily hold somewhat more data than its "delete backups after" setting alone would suggest — particularly when the clean-up period is shorter than the time between scheduled full backups. SQL Backup Master will point this out when you configure such a destination.

Retry Failed Storage Attempts

In addition to the backup job retry mechanism available in the Scheduling configuration window, SQL Backup Master can retry failed backup file uploads.

This feature affects only the file upload phase of backup job processing, and can help mitigate transient failures (server disconnects, etc.) without re-running the entire backup job.