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.

Incomplete Uploads (S3-Compatible Storage)

When a large backup file is sent to an S3-compatible destination (Amazon S3, Backblaze B2, Wasabi, MinIO, and others), SQL Backup Master splits it into parts and uploads them using the S3 multipart upload API. If an upload is interrupted - a network stall, a cancelled job, a service restart, or a server-side error - the parts that were already sent remain on the storage provider as an incomplete multipart upload.

Important: Incomplete multipart uploads consume storage and are billed by most providers, but they do not appear in normal bucket file listings - including SQL Backup Master's own remote file browser and storage metrics. It is therefore possible for a bucket to bill for noticeably more storage than its visible contents suggest.

The recommended way to reclaim this space is a bucket lifecycle rule that automatically aborts incomplete multipart uploads after a set number of days. Most S3-compatible providers support this (it is usually called abort incomplete multipart upload or similar); consult your provider's documentation for the exact steps. A few points worth keeping in mind:

  • Choose a threshold longer than your slowest upload. A very large backup over a slow connection can legitimately take many hours. Seven days is a safe starting point; one day may be too aggressive.
  • A lifecycle rule catches everything. It reclaims parts left behind by any cause - including a server crash or power loss, which no application-level clean-up can reach.
  • SQL Backup Master also sweeps. During each destination clean-up pass, SQL Backup Master aborts incomplete multipart uploads in the bucket that are more than seven days old. This is a backstop for buckets without a lifecycle rule, not a replacement for one. The seven-day threshold is deliberately conservative because the storage API does not allow an application to distinguish its own interrupted uploads from those of other tools or servers using the same bucket.
Note: If several backup jobs or servers write to the same bucket, do not shorten the sweep threshold. An aggressive value risks aborting an upload that another job still has in progress.