SQL Backup Master Blog

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.

In rare cases, SQL Backup Master may log the following error when attempting to perform a differential database backup:

Failed to create backup: Cannot perform a differential backup for database “XYZ”, because a current database backup does not exist.

This error occurs because the SQL Server backup chain for the specified database is being invalidated. Let’s review possible causes.

Possible Cause #1 – VSS (Volume Shadow Copy Service) Backups

Some third-party backup solutions will take a snapshot of your SQL Server database via the Windows Volume Shadow Copy Service. These snapshots will invalidate the current backup chain, thereby interfering with tools such as SQL Backup Master.

Important: SQL Backup Master 6 and later includes a Backup History report that can help identify when this problem occurs. Select the Reporting tab in the main product window and select the Backup History report. When viewing the report, look for entries that have the Is Snapshot field set to True. These backups are not being created by SQL Backup Master.

VSS creates database backups through a Windows system service called SQL Writer Service. When enabled, this service allows backup applications to copy SQL Server data files while SQL Server is running.

The solution in this case is simple – disable the SQL Writer Service, as follows:

1. Press Windows + R keys to open the Run dialog, then type services.msc and press Enter.
2. Find the SQL Server VSS Writer service and double-click on it.
3. Click the Stop button to stop the service, when change the startup type to Manual.
4. Click OK to finish.

When the service has been disabled, use SQL Backup Master to trigger a full database backup to re-establish the state of the backup chain.

Possible Cause #2 – Changing the Recovery Model

If the SQL Server database recovery model has recently changed, you should manually trigger a new full backup in order to reinstate the database backup chain. Once this is done, future differential backups should run successfully.

Possible Cause #3 – SQL Server 2005 Bug

Microsoft knowledge base article #921106 describes a bug in SQL Server 2005 that can cause this problem. The KB article also provides a hot fix.

Still Need Help?

If you’ve reviewed the above causes and solutions are still experiencing this problem, please feel free to contact our support team. We’re always happy to help.

When searching for a software based solution to a problem, trust clearly matters a great deal. Never is this more true that in the case of database backup software. After all, what good is a SQL Server database backup solution if you’re uncertain about the viability of the backups it creates?

In this article, we’re going go take a closer look at the transparent operational nature of SQL Backup Master, the company behind it, and your role in ensuring backup chain confidence.

SQL Backup Transparency

One of the best attributes of SQL Backup Master is that it isn’t doing anything magical or proprietary behind the scenes. SQL Backup Master leverages the native backup capabilities of SQL Server itself to create raw database backup files. It then compresses (and optionally encrypts) the backup using the compression algorithm of your choice (or none at all, if you prefer) and uploads it to your configured backup destination(s).

What this ultimately means it that you’re not required to use SQL Backup Master when it comes time to recover a database from backup. Of course, SQL Backup Master has a helpful database recovery option available to you – but it isn’t doing anything that you can’t do manually should you choose to do so. In fact, manual recovery is as simple as downloading the backup file from your backup destination, decompressing it using readily available tools, and then restoring the database directly via SQL Server (which can be done using SQL Server Management Studio or SQL statements).

I really can’t stress this point enough – SQL Backup Master adds considerable value to the SQL Server database backup process without stripping you of the freedom to adapt. And, just as importantly, database recovery process isn’t locked behind some expensive licensing paywall of a third party software company. Your data is your data, after all, and that’s how it should remain.

Pedigree of Key Metric Software

Another consideration when choosing a database backup solution is, of course, the software development company behind it.

Key Metric Software has been operational since 2003 and has a number of very well-regarded software products on the market – all actively developed and supported. We have over 50 thousand paid customers (plus many more using the free versions of some of our products) around the world – and our support services are world-class.

The goal of Key Metric Software has always been to create strong value propositions for organizations of all shapes and sizes, and SQL Backup Master is a critical part of that vision.

Your Role in Database Backup Security

Confidence in your SQL Server database backup and recovery strategy ultimately begins and ends with you.

When evaluating a database backup software solution, be sure to put the product through its paces by testing the entire backup chain from backup to recovery. You should also plan on re-testing the backup chain periodically to establish an ongoing sense of security and confidence.

After all, a database backup is only valuable if it can be recovered when needed.

Some users of SQL Backup Master may encounter the following error when executing a database backup job (or testing one during the configuration process):

Job Execution Error: Cannot open backup device ‘<Path>’ Operating System error 3 (The system cannot find the path specified. BACKUP DATABASE is terminating abnormally).

The key to solving this problem is to first understand that SQL Server must be able to write database backup files directly to the temporary backup folder location specified in your backup job settings.

When SQL Server cannot access this temporary folder location, the database backup file cannot be created and the process fails with “Operating System error 3”. Now let’s look at possible underlying causes.

Possible Cause #1 – Permissions

Regardless of how you configure a backup job within SQL Backup Master, SQL Server itself runs within the security context of the account specified in the SQL Server system service configuration. To find out which account is being used click Start, click in the Start Search box, type services.msc, and then press ENTER.

Find your SQL Server instance in the services list and double-click it, then select the Log On tab.

It is this “log on” account that must have sufficient permissions to write to the temporary backup folder location. Check the permissions on the temporary backup folder by right-clicking it in Windows Explorer, selecting Properties, then navigating to the Security tab. Make sure that the account SQL Server is using has explicit read/write permissions for this folder.

Also, here’s a quick tip. If you’re uncertain as to whether folder permissions are at the root of your problem, just temporarily give “everyone” full permissions to it. If your backup job tests and executes successfully after doing so, you’ll have confirmed that permissions problem are the root issue and can narrow them down from there.

Possible Cause #2 – Mapped Drives

If you’re attempting to specify a backup folder location that resides on a remote (network ) file system, we strongly recommend that you do not use a mapped drive letter for this purpose. In Windows Vista and later, mapped drive letters are bound to the Windows security context that was used to create them, and SQL Server will usually not be able to access the mapping for this reason.

The solution to this problem is simple: use a fully qualified UNC path instead of a mapped drive letter. So, for example, instead of using “Z:\DBBackups” (where Z is the mapped drive letter), specify a fully qualified UNC path such as “\\remote-server\DBBackups”.

Possible Cause #3 – Lack of Domain Trust

If your SQL Server instance and your database backup folder are on computers in separate Active Directory domains, then a missing or expired trust between the domains may cause this problem – even if the file system permissions are configured appropriately.

You can resolve this issue by ensuring that a trust between the two domains is established. You may also need to configure the SQL Server service account with pass-through authentication between the domains.

Conclusion

When using SQL Backup Master, “Operating System Error 3” is an indication that SQL Server is unable to write to the temporary backup folder location specified in your backup job settings.

If you need further assistance with troubleshooting this problem, please don’t hesitate to open a support request with us. We’re happy to help.