The 15 Minute Backup Strategy

For a long time our only backup strategy was to take a full backup of the database every night and try not to worry about it too much. Eventually the database grew to a point where the job that copied the backups to off-site storage couldn't keep up any more, not to mention that all that copying was consuming some serious bandwidth. Then some bright spark realized we couldn't really afford to lose a whole day of work if the server ever crashed and we had to restore the last backup. We obviously needed a better plan.

While any good DBA will tell you there are a million things to consider when deciding on your backup strategy, we needed a plan that was simple enough for a developer to implement and maintain. It also had to create small(er) backups and provide better coverage. Too complicated? Well, we came up with a pretty good solution.

To improve our coverage, we could take more frequent transaction log backups since they are small and fast even with a reasonably large database. The only problem is that log backups have to be restored sequentially on top of the correct full backup. If one of those files is corrupt, all the data from that file onwards is lost. So, we didn't want too many log backups.

On the other hand, we had to reduce the frequency of the full backups to ease the load on the bandwidth. That's when we turned to differential backups to fill the gap. Differential backups are cumulative i.e., they include any changes that occurred since the last full backup. To restore, you only need to apply the last differential on top of the correct full backup. The downside is that, over time, the differential backup will grow to the same size as the full.

This lead to our three-pronged approach. We decided to have:

• full backups once a week
• differential backups every 4 hours
• transaction log backups every 15 minutes
  

In the event of a crash, we lose at most 15 minutes worth of data. The backup set shrunk in size from 7 full backups a week to 1 full backup, 1 differential backup and, at most, 15 transaction log backups (to cover the period between differentials). The restore procedure is a bit more complicated than just restoring a single full backup but not by much. There are up to 17 files to be restored and this can easily be automated by a stored procedure or script. Overall, it's a pretty good improvement over the previous strategy.

Does ASPState need full recovery?

I prefer to use SQL to keep session data in my ASP.NET applications. In order to do so, you need to create the state database (usually called ASPState) in SQL Server. Have you noticed that its transaction log will keep growing unless you take regular backups?

I don't know about you, but I don't really need backups of my session database (the main application database is a different matter, of course). The data that I store in session is very transient. If it ever crashes, I'm not going to try to recover the data. I'm happy to recreate the (empty) database and let the users come back to the application with a brand new session.

So, what's the solution? Well, I set the ASPState database to use the simple recovery model. Once that's done, the transaction log won't be a problem any more. Additionally, if you already have a large transaction log, you might want to shrink it after you change the recovery model.

Auto Login in Firefox

Here's the setup: I'm building a web application that's only accessed by users within a Windows network. The application authenticates the users by their Windows logins and to make things interesting, the users prefer Firefox.

If they used IE, the browser would automatically send the user credentials to the web server (the same credentials used to log in to the Windows domain in the first place). Firefox, on the other hand, will ask the user to re-enter their username and password. A small annoyance but annoying just the same.

Well, there's a way to avoid it. Go to about:config (type that into the address bar), look for a setting called network.automatic-ntlm-auth.trusted-uris and add the URL of the application as the value. Problem solved!

It's not a novel solution – in fact it's described on a number of different websites. I happened to find it on Stack Overflow.

Don't forget to show the page

If you ever find yourself writing Postscript documents by hand, or creating an application that writes them, don't forget to use the showpage operator. You typically want to call it at the end of each page in your document since it tells the Postscript interpreter to grab all the things you've drawn up to that point and actually render them into a page.

Yes, I know it sounds obvious - who would forget to do that, right? All I can say is it happened to me recently. Both GSview and an office laser printer I was using to test the document displayed it fine without including the operator. I guess they figured, "Well, you've drawn a bunch of things on the page, and I've reached the end of the document, surely you want me to print something so I'll go ahead even though you didn't tell me to do that".

My problem was that the production press the document was intended for didn't use the same common sense approach. It RIP'ed the document without errors and then just sat there (with a smug look on its face, I'm sure). It makes sense, once you realize what's going on, but it took quite a while to figure it out. Anyway, remember to add showpage and everything will be fine.