SQL Backup Master Blog

Key Metric Software is proud to announce the general availability of SQL Backup Master 5. This new, major version offers a wide range of improvements and new features.

Learn about what’s new in SQL Backup Master v5.

We’re excited for you to get your hands on the new version. As always, we recommend testing your existing backup jobs after upgrading.

Existing standard or pro edition customers can upgrade to v5 at a 50% pricing discount (vs. new licenses).

Download SQL Backup Master v5 when you’re ready to upgrade.

If you encounter the above error while attempting to restore a differential backup, it usually indicates that it’s being applied to a full backup that isn’t the most recent one.

The most common cause we’ve seen is that a third-party program (or a SQL admin) is creating full backups in addition to the ones created by SQL Backup Master. And this means a more recent full backup likely exists somewhere about which SQL Backup Master has no knowledge.

In other words, a full backup was taken in between the full and differential backups being performed by SQL Backup Master. This results in a broken backup chain.

The very latest full backup must be located and restored prior to any differential what was derived from it. The differential cannot be restored to any prior backup (it must be the latest full backup that was created).

Diving deeper

If additional details are required, we recommend querying SQL Server’s backup set records. Doing so can help you identify where breaks in the backup chain may be occurring. Here’s a SQL query to get you started – you may wish to further restrict it by database name, time frame, etc.

SELECT 
msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_start_date,
msdb.dbo.backupset.backup_finish_date,
msdb.dbo.backupset.database_backup_lsn,
msdb.dbo.backupset.differential_base_lsn,
CASE msdb..backupset.type
WHEN 'D' THEN 'Full'
WHEN 'L' THEN 'Log'
WHEN 'I' THEN 'Diff'
END AS backup_type,
msdb.dbo.backupset.backup_size,
msdb.dbo.backupmediafamily.physical_device_name
FROM msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset ON
msdb.dbo.backupmediafamily.media_set_id =
msdb.dbo.backupset.media_set_id
ORDER BY 
msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_finish_date

Sample query results shown below demonstrate how to correlate a differential backup to a specific full backup. The magnified portion of the screenshot shows a differential backup with a differential_base_lsn field correlating to the first_lsn field of the full backup that precedes it.

The data provided by this query should help you to locate backup chain breaks. For additional information on querying this information from SQL Server, please see the link below.

backupset (Transact-SQL) – SQL Server | Microsoft Docs

Recommendations

The long-term solution to this problem is to ensure that only SQL Backup Master is creating SQL Server backups for your databases. Disable all other automated or scheduled SQL Server backup services for those databases, and use the SQL Backup Master GUI to create manual backups if needed.

We get a fair number of questions from SQL Backup Master users about transaction log files, often accompanied by concerns regarding truncation and/or shrinking of log files.

We’ll start with the summary. It isn’t necessary to manually truncate SQL Server transaction log files. However, there may be an occasional need to manually shrink them.

We’ll talk about log truncation first. Truncation is a process that frees up space in the log file for reuse. It will occur automatically at regular checkpoints if your SQL Server database is using the simple recovery model. If the database uses the full or bulk-logged recovery model, truncation occurs automatically after each log backup.

Which recovery model your database should use depends on whether your recovery plan includes a requirement for point-in-time recovery. If not, then use the simple recovery model. Otherwise, SQL Server needs to use the full or bulk-logged recovery model and transaction log backups become a requirement (otherwise they will not truncate and will continually grow the log file).

Which brings me to the final topic of this blog – log file shrinkage. This should be an uncommon operation that is performed manually (usually as part of a database migration, bulk import, etc.), and not part of any maintenance or scheduled backup operation.

It’s a simple question. Does your company operate a SQL Server database for anything important?

If you’re unsure, keep in mind that various editions of Microsoft SQL Server are quite ubiquitous as the data storage back-end for a wide range of modern software products. SQL Server instances also often support internal software and web development operations, with their footprint expanding considerably due to recent (and very robust) support for Linux.

But yes – you’re running SQL Server in some capacity. Why else would you be here given the title of this blog? And you must have a backup strategy for the databases you care about (which is often all of them).

But you already know that you need database backups. And maybe you’re using our SQL Backup Master tool to help with that. That would be good.

But there’s something even more critical here than SQL Server backups themselves. It’s the data they contain, and your ability to restore said data. And yet, this part of the overall backup strategy gets missed a lot, perhaps to the peril of an admin who’s just realizing key backups weren’t running (permissions error) and error notifications were going to an unmonitored email account. Yikes.

Such sullen scenarios, however, are easily avoidable. We’ll use a simple inspirational phrase to help us remember.

Backups are useless unless they can be restored – and you must regularly ensure that they can be.

So we return to the title of this blog entry – the importance of database backup recovery testing. At a minimum, define a test plan that reflects the potential impact of data loss to your organization. Take the time to catalog the SQL Server instances on your network, assessing the criticality of each.

And keep in mind that SQL Backup Master is a perfect solution for any instances of SQL Server that need backing up. It makes it easy (and free) to store backups of any SQL Server instance’s databases in the cloud (or on a NAS, FTP site, etc.).

Finally, use your planning results to inform and execute end-to-end recovery tests at regular intervals. Skip this step only if you value good fortune over verifiable results.

Good news! Our friends over at Backblaze have implemented an S3 Compatible API for their B2 Cloud Storage service. This means you can begin using SQL Backup Master to back up SQL Server databases to Backblaze B2 Storage Cloud immediately.

Backblaze has developed the following guidelines for using their S3 compatible API:

https://help.backblaze.com/hc/en-us/articles/360047425453?_ga=2.139630771.1231181358.1588627186-640778578.1588020441

Important: As noted in the article above, B2 Storage buckets created prior to May 4th, 2020 are not S3 compatible. You can work around this by simply creating a new bucket for storing your database backups.

Overall, we think this is excellent news for SQL Backup Master users. Thanks to the recent development work put forth by Backblaze, you can now safely store SQL Server backups in their B2 Cloud Storage platform – one of the most robust and cost effective storage options available today.

For details on how to integrate SQL Backup Master with S3 compatible services, please see our blog post on the subject.

Key Metric Software is proud to announce the release of SQL Backup Master v4.6, with official support for SQL Server 2019. Other improvements include NTFS long path support for folder backup destinations, improved logging, and updated communications libraries for a number of popular backup destination types.

Download the latest update from our product website:

https://www.sqlbackupmaster.com/download

In SQL Backup Master v4.5, we added support for the rapidly growing number of storage services and devices that offer Amazon S3 protocol compatibility.

A good example of such a service is Wasabi, a secure cloud storage provider that bills itself as being “simple, affordable, and fast”. You can learn more about their commitment to S3 protocol compatibility here.

Configuring SQL Backup Master to use Wasabi (rather than Amazon S3) is extremely simple. Just configure the Amazon S3 backup destination to override the Service URL, as shown in the screenshot below.

It’s important to note that some S3-compatible storage services (including Wasabi) will not support every Amazon S3 feature. For example, Wasabi does not (at the time of this writing) support bucket-level transfer acceleration or the GovCloud regional endpoint – and will silently ignore any attempts to use such features. For this reason, we recommend that you always make sure you review any S3-compatible storage provider’s compatibility statements prior to using them.

Still, Wasabi worked very well in our SQL Backup Master compatibility tests – and there are many other examples of Amazon S3 compatible services and hardware devices (including QNAP QTS) available.

Key Metric Software is proud to announce the release of SQL Backup Master v4.5.

This new version includes a number of helpful improvements, including formal support for Windows Server 2019, custom script execution timeout support, the ability to export backup logs as HTML, and much more.

For a full list of changes, please see the SQL Backup Master product release notes.

Did you know that SQL Backup Master makes it easy to back up SQL Server databases running on Linux?

Using SQL Backup Master for this task offers a broad range of benefits:

• Provides backup scheduling for SQL Server (including Express edition) on Linux
• Allows database backups to be stored on-site (local folders, network folders, NAS devices, etc.)
• Allows database backups to be stored off-site (FTP, Dropbox, Google Drive, Amazon S3, OneDrive, etc.)
• Provides database backup compression and encryption capabilities
• Provides email notification support for database backup jobs
• Many other features (robust backup logging, retry support, recovery support, etc.)

For details, please see our Backing Up SQL Server on Linux article.

SQL Backup Master v4.3 introduced the ability to pass custom parameters to the database backup command that is sent to SQL Server. One example of how this capability can be useful is if you wish to enable SQL Server’s built-in backup compression capability.

Before you begin, though, keep in mind that native backup compression is available only in certain versions and editions of SQL Server. You’ll need the Enterprise or Standard edition of SQL Server 2008 R2 or later to use this feature – it isn’t supported in lesser editions such as Express, Web, etc.

It’s also worth noting that SQL Backup Master’s compression feature will typically yield superior results than SQL Server’s built-in backup compression. However, SQL Server’s backup compression feature has the advantage of requiring less working disk space and in some cases might be a better fit for your backup workflow.

To enable SQL Server backup compression in SQL Backup Master:

1. Double-click your backup job in the SQL Backup Master main window
2. Click the Backup job settings link
3. Select the Database tab
4. Enable the Append the following arguments to the backup database command checkbox
5. Add the keyword COMPRESSION to the backup database command arguments field

The result is shown in the screen shot below.

Next, you’ll likely want to disable SQL Backup Master’s compression feature. Although you aren’t strictly prohibited from using it in conjunction with SQL Server’s built-in backup compression, you won’t typically see much (if any) benefit from doing so. To disable it, select the Compression & Encryption tab in the backup job settings window and select the Compression Disabled option.

You can now save your changes and execute the backup job. The resulting database backup will have a .bak file extension and should be appreciably smaller than its uncompressed counterpart.

IMPORTANT: We strongly recommend that you run backup and restore tests every time you change your backup job settings – especially when using advanced features like the one described above.