Distinguish backup file names or pay the price!

Running around a track

SQL instances shouldn’t do this

So far, no one has found exercise to be beneficial to servers. Purposeless repetitive motion may be good for human muscles, but your SQL Server instance experiences no gain for the pain.

Here’s a good example: taking useless backups.

(“Did she say useless backups? I’ve never heard of such a thing!” Yeah, just wait.)

Backup file names are critical

Traditionally, backup files are named after the database and the backup type, and given a timestamp. So you’ll see something like master_FULL_20170101.bak. If you like to stripe your backups, you might name the files something like 1of5MasterFull20170101.bak, and so on.

But I have run across shops that takes backups without bothering to time stamp the file name: master_FULL.bak.  These shops either overwrite each backup file, with each successive backup (using INIT and FORMAT), or add to the backup set (which I find mildly annoying, but to each their own).

The problem with using the same backup file name over and over is if you have a cleanup mechanism that deletes old backup files!

The same-name cleanup issue

Let’s say that in your shop, you have Minion Backup (MB) installed and running with the following options:

  • INIT is enabled
  • FORMAT is enabled
  • Backup file retention (in hours) is 48, so we’ll keep 2 days’ worth of backups
  • Backup name is set to %DBName%%BackupType%.bak, which works out to DB1Full.bak for a full backup of DB1.

Note: For more information on the %DBName% and %BackupType% inline tokens, see “About: Inline Tokens” in our help center.

Here is what happens:

  1. On day 1, MB takes a backup of DB1, to \\NAS1\SQLBackups\DB1Full.BAK.
  2. On day 2, MB takes a backup of DB1, which overwrites the file \\NAS1\SQLBackups\DB1Full.BAK.
  3. On day 3, MB takes a full backup of DB1 (which overwrites the same file). And then the delete procedure sees that it has a file from day 1 (>48 hours ago) that needs deleting. And so it deletes \\NAS1\SQLBackups\DB1Full.BAK. Remember, this is the file that MB has been overwriting again and again.
  4. On day 4, MB takes a backup of DB1, to \\NAS1\SQLBackups\DB1Full.BAK.. Then, it sees that it has a file from day 2 that needs deleting, and so deletes \\NAS1\SQLBackups\DB1Full.BAK.

See? From Day 4 on, we’re creating a backup file just to delete it again!

Fixing the issue if you have MB

One excellent way to figure out if you have this problem is to notice that, hey, you don’t have any backup files. Another indicator in Minion Backup is if you see “Complete: Deleted out-of-process. SPECIFIC ERROR:Cannot find path ‘…’ because it does not exist.” in the Minion.BackupFiles Status column.

But the real smoking gun is if you haven’t time stamped your backup files in Minion.BackupSettingsPath. Here’s how to fix that:

    UPDATE Minion.BackupSettingsPath
    SET FileName='%Ordinal%of%NumFiles%%DBName%%BackupType%%Date%%Hour%%Minute%%Second%';

That will give each file its own name, and eliminate the chance of this ever happening.

And it will prevent your server from performing useless exercise. Me? I’m going to hit the gym.

Technology: Shoot yourself in the foot faster!

Most of us love technology. And most of us have experienced how blindingly fast technology can provide some degree of cataclysmic failure. Let me explain.

I’ve been getting better and better about planning out my work week, listing out what needs doing each day, and sticking to it. So I knew that today I would be working a little on a few website updates in the morning, and then the rest of the day would be free for coding.

(I pause here for the audience to have a hearty chuckle.)

So here we are. I log onto the WordPress back end for MinionWare.net, change the wording and format of some text elements, and double-check that they look okay.

The other thing on my list is making sure I have a specific plugin installed. Is it? Why, yes it is! That’s grand, I guess my work here is about done.

But hey, look at that. A bunch of the other plugins need updating. I should go ahead and do that real quick…

(I pause here for the audience’s gasps of horror.) But wait, let me reassure you: I did pause and download a fresh WP backup.

And then I updated three WordPress plugins. Why, oh why did I do that? Why, when I know better?

The website came up as gibberish. Every page, every post, came up as complete gibberish. Of course I immediately restored the WP backup…which did absolutely nothing to help. It turns out that these backups are pretty much for content, not for restoring plugins to a specific state.

Goody.

After a good deal of fighting and rage-coffee, I narrowed everything down to one culprit, killed the plugin with fire, and confirmed that the site was up and looking good.

Why is it so much easier to destroy than to fix?

This is totally a common theme in life. From the big glass bowl my kid shattered in the sink, to the car we (I won’t say who) scraped against a wall, to the appointment we missed. So much of our time is spent cleaning up mistakes, paying to have them fixed, and making up for lost time.

And technology lets you break things so much faster! I can drop a bowl and spend 30 minutes cleaning it up, but I can drop 2 Tb of data without a thought and spend weeks trying to get it back. (I mean literally, that’s what it takes to drop 2Tb…not thinking at all.) I can scrape the paint on my car and just leave the thing scraped…but I can bring down a years-old website with the click of a button.

You see a theme here?

I’m starting to see that a large percentage of an IT professional’s life is (or should be) disaster prevention – teaching yourself to triple check what server you’re connected to, making sure backups are up and running. And another very large percentage is disaster recovery, in one form or another. Yes, of course I mean traditional SQL disaster recovery. But I also mean recovering from the borked website, the forgotten perfmon trace, the third missed meeting this week (where your manager noticed particularly that you weren’t there).

Prevention and recovery

With technology, as with life, automation is a huge part of the solution. But, it’s not the whole solution.

  • We can automate database backups.
  • We can automate WordPress Backups.
  • We must set reminders for meetings.
  • We must set reminders to get the car’s oil changed. (Also: to keep off your dang phone while driving.)
  • We should create standard procedures for maintenance and downtime.
  • We should create standard procedures for managing personal tasks. (I’ve become a huge fan of the Bullet Journal method for this.)

And of course, we can’t prevent everything. So sometimes, we spend the morning staring furiously at wp-admin folders in FileZilla, instead of coding.

Good luck with the chaos.

-Jen

Five minutes to freedom: Installing Minion Enterprise

Let’s take five minutes and get our entire enterprise in order.

Get your repo server, your Minion Enterprise download, and your license key (trial or permanent). Install and config take just five minutes.

02-Install1. Install

Extract the MinionEnterprise2.2Setup.exe and run it on your repository server.  Give the installation “localhost” for the instance name.

2. Configure email for alerts

Connect to the repo server and insert your alert email:

USE Minion;
GO
INSERT INTO dbo.EmailNotification ( EmailAddress, Comment )
SELECT 'Your@Email.com' AS EmailAddress, 'DBA' AS Comment;

3. Configure servers

Insert (or bulk insert) server to the repo:

INSERT INTO dbo.Servers
(
 ServerName,
 ServiceLevel,
 Port,
 IsSQL,
 IsActive
)
VALUES
 ( 'Prod01', 'Gold', 1433, 1, 1),
 ( 'Prod02', 'Gold', 1433, 1, 1),
 ( 'Prod03', 'Silver', 1433, 1, 1),
 ( 'QA01', 'Silver', 1433, 1, 1),
 ( 'Dev01', 'Bronze', 1433, 1, 1),
 ( 'Dev02', 'Bronze', 1433, 1, 1);

4. You’re done!

Jobs will begin kicking off to collect data within the next hour. Some jobs run hourly, some run daily or weekly or monthly. You’ll start getting tables full of useful data, and email alerts that actually mean something.

If you’re impatient to start getting some of the good stuff right away, kick off the CollectorServerInfo% jobs manually. These populate data in the dbo.Servers table, which other jobs need to run. You’ll start noticing data in the Collector.DBProperties, Collector.ServiceProperties, and Collector.DriveSpace tables first, as these jobs run most frequently.

While ME is taking care of your shop for you, you can get to know it better with the online documentation!

Download our FREE maintenance modules below:

  • Minion Backup: Free SQL Server Backup utility with world-class enterprise features and full lifecycle management.
  • Minion Reindex: Free SQL Server Reindex utility with unmatched configurability.
  • Minion CheckDB: Free SQL Server CHECKDB that solves all of your biggest CHECKDB problems.

SQL maintenance is a lifecycle, not an event!

You’ve heard me talk about this many times, in so many different ways, but it’s worth repeating: SQL maintenance lifecycles are important.

People who disagree, disagree because they spend too much time firefighting and don’t have time to really think about it.  Don’t know anything about SQL maintenance lifecycles? Let’s touch on a couple of points…today, we’ll cover SQL backup.

SQL maintenance lifecycles: Backups

Backups have the biggest lifecycles of all, because the uses for backup files are so varied.

They’re used for restoring databases to the original server, sure.  But here’s a short list of the other kinds of things you need to do with backup files:

  • Restore to development, QA, etc.
  • Send to vendor
  • Initialize replication
  • Initialize Availability Groups
  • Restore to a secondary server to run CheckDB

A backup is not a single event

A database backup isn’t a single event.  But unfortunately, nearly every vendor out there – and most DBAs – treat backups as a single event that has a start and a finish.  “Look, I took a SQL backup and produced a file, and now I’m finished!”  But that’s not remotely the case.  We use and shuffle SQL backup files around all day and all week long on our various servers.

This is why I’m so against those tools that I call “network backup tools”.  You know the ones: Backup Exec, AppAssure, etc.  Your network admin loves those tools, because he doesn’t understand SQL and he wants the same backup utility for the whole shop.

But network backup tools simply aren’t going to cut it for SQL maintenance lifecycles, because they take snapshots of the data and log files.  And quite often those two files aren’t fully synchronized when the snapshot takes place, so you wind up creating a new log file and losing whatever data was in there.  Not only that, but you can only attach those files somewhere, usually on the same server they came from.

Without the understanding that your maintenance has a lifecycle, you wind up with a lot of piecemeal solutions.  You write something to restore a database on a development box, then another DBA does the same thing, then another, then another.  Soon you have a huge mix of solutions that need support, all created by a mix of DBAs over the years…it’s an unmanageable web of solutions, each one with its own quirks and limitations.  That’s no way to run a shop, and it’s no way to support your data.

SQL Maintenance Lifecycles: SQL backup done right

Minion BackupThis is why we’ve made Minion Backup the way we have.  Minion Backup is the only backup tool on the market that treats your environment holistically.  Minion Backup understands your SQL maintenance lifecycle and it works for you to provide you built-in solutions that you just deploy.  There’s no need to write your own processes, or manage something separate because it’s built into Minion Backup by default.

Let’s take for instance that you need to back up your SQL certificates, because you know, who doesn’t?  With Minion Backup you can easily backup every certificate, even to multiple locations.  In fact, you can back up your certificates to as many locations as you need.  This functionality is built into Minion Backup, and setting it up is a simple table setting.

Not only that, but since we store the private key password encrypted, and give it to you in the log, you can even rotate the private key passwords on any schedule you like to increase your security.  This way if you change the private key password every month, then you’ve always got access to the encrypted value in the log so you can restore that certificate with ease.  This is what we mean by SQL maintenance lifecycle management.  All of our SQL maintenance products have this level of lifecycle management.  And we’re improving them all the time.  We work closely with our users to give them built-in solutions that matter.

All of our SQL maintenance products are completely FREE, so download them and try them now.  And if you like what you see, then try our enterprise products and see the power of bringing your SQL maintenance lifecycles into the enterprise architecture.

Download our FREE maintenance modules below:

  • Minion Backup: Free SQL Server Backup utility with world-class enterprise features and full lifecycle management.
  • Minion Reindex: Free SQL Server Reindex utility with unmatched configurability.
  • Minion CheckDB: Free SQL Server CHECKDB that solves all of your biggest CHECKDB problems.

 

Integrity Checks are Useless*

Integrity checks have become more and more important over the years, as companies store more and more data. This data is absolutely critical, so when corruption happens, it can break a company.

But in all but the smallest shops, running any kind of integrity check is all but completely useless.

Integrity checks without management

DBCC CHECKDB was originally written without consideration of management. For a very long time, you could only output CHECKDB results to the client – meaning you had to run it by hand – or to the error log. Seriously, what good is that? Later, Microsoft added the ability to output CHECKDB results to a table, but that remained undocumented for years so very few people knew it even existed.

That’s not the only problem. A lot of DBAs don’t run CHECKDB at all, because large databases take a long time to process. CHECKDB takes an internal snapshot for its operations. For large databases, that snapshot can fill up the drive, killing the integrity check process entirely. So, you have nothing to show for your efforts. Some DBAs tried to get around this issue by moving to CHECKTABLE instead, but that process comes with the same issues, and is even harder to manage because there are so many more tables than databases.

Integrity checks without reporting

Another reason that running DBCC CHECKDB is useless is this: reporting is still very difficult. Let’s say you have 50 servers – yes, I know a lot of you may have many more than that – and CHECKDB is set to run through a maintenance plan, outputting results to the SQL error log. In this scenario, you have to mine the log for CHECKDB results. That means you not only have to know when the CHECKDB completes on each and every server, but you also have to know what the log entry will look like, and how to parse out the results so they’re readable…again, on every single one of 50 servers. There is simply no easy way to consume CHECKDB results on any kind of scale.

Useful integrity checks with Minion CheckDBMinion makes integrity checks useful again

The whole goal of Minion CHECKDB was to transform these issues surrounding integrity check processing into simple settings. Now DBAs of every skill level can have a stable, standardized integrity check process for even their largest databases.

Minion CHECKDB has a huge number of groundbreaking features. MC solves the reporting problem by capturing integrity check results to our own log table, along with a huge amount of additional information. Now it just takes a simple query to get the results. Instead of the native raw CHECKDB results, the MC log table tells you how many corruption errors were encountered. Then you can drill deeper from there if you like.

We’ve also solved the problem of the large database that can’t be processed because it runs out of snapshot space. In fact, we’ve solved that a few ways, and I’ll discuss a couple of them here.

  • You can create a custom snapshot on a different drive that has more space. MC manages those snapshots for you, so it’s literally a set and forget operation.
  • Or, you can restore a recent backup of your database to a remote system and run CHECKDB against that instead. Remote CHECKDB even brings the results back to the primary server, so you don’t have to go hunting for them. Again, this is a setting; you configure it, and then MC manages the whole process for you.

Of course, there’s more

There are many more features in Minion CHECKDB that I didn’t mention. But since MC is completely free, you can download it and install it on as many instances as you want. Go explore!

Put MC on all your systems and start doing integrity checks again. We’ve taken away all the excuses. And when coupled with Minion Backup and Minion Reindex (both also free), you’ve got a maintenance suite that meets all your needs from planning to reporting, and everything in between.

 

*Without proper management and reporting!

Webinar: Introducing Minion CheckDB!

 

productimg_checkdb

Minion CheckDB is available for download as of February 1, 2017!

In celebration, we had Minion CheckDB webinars.

Done: And, we will be giving away 3 licenses of Minion Enterprise to one lucky winner* at each webinar. Must be present to win! 

Minion CheckDB completes the MinionWare maintenance and backups suite in style. Each solution is plug-and-play for the busy DBA, and deeply configurable for those shops with in-depth needs.

This new module is MinionWare’s most ambitious free release yet, featuring all of the rich scheduling and logging functionality in previous products, plus remote CheckDB, multithreading, custom snapshots, rotational scheduling, and more.

In this webinar we’ll show you how this FREE tool by MinionWare can meet your needs with almost effortless management. You are going to LOVE it.

If you simply can’t wait, check out the Minion CheckDB tutorials!

*(Giveaway offer is not open to previous ME winners.)