You’re now reading the 4th and final post in my SQL Server Backups to Azure series. In previous posts I’ve described how to set up an Azure Storage Account, Blob Storage container and how to take SQL Server backups there. This time we’ll take a look at one more option that puts our backups on autopilot, with destination to cloud!
The feature I am writing about is Managed Backups, an option that has been available since SQL Server 2014 but one that I have not seen often used. One reason for that, maybe being, that there’s an unfixed feature that makes enabling it a bit difficult if you’re not aware of the workaround.
Despite this shortcoming, if you have SQL Servers (on-premise or Cloud) but no DBA to care for them, I’d recommend that you take a look at this option.
You are now reading the 3rd part of the 4 part series on backing up databases to Azure. In Part 1 we looked at some benefits of using Azure for your backups and in Part 2 we set up the Storage Account with the Block Blob storage container.
In this post, we’ll take a look at how to use the freshly created Blob storage with our customized backup routines.
This is the second part of a 4 part blog post series about backing up SQL Server to Azure. If you wonder why you’d like to back up data to Azure in the first place, please read the Part 1 of this series that explains some benefits of using Azure for backups.
In this post, we’ll look at how to set up your very own Storage Account and how to use some nice security features in it.
I’ve said it before, and I say it again: Understanding how database backups and restores work is one of the more important topics for DBAs to understand. This time we’ll approach the topic from the cloud, and more precisely, from the Azure perspective. Why cloud perspective, you might as? For one simple reason. Even if you’re not (yet) running your SQL Server workloads in Azure, it doesn’t mean that you can’t make use of it for other purposes, such as backups. And while the idea of placing your data into Azure, or into any other cloud platform, might still seem scary to some, I want to help put your minds at ease. To accomplish this, I’ll just point you to this fine piece of documentation describing the Azure infrastructure security. I think you’ll find it quite satisfying.
As there’s quite a few topics to cover with database backups to Azure, I have split the details into 4 separate posts. You’re now reading Part 1, the introduction.
Backups, backups, and backups. That’s pretty much my answer to what should be the top 3 priority topics that any DBA needs to understand well. And that’s what we’re going to be looking at this post, backups! Backups play a vital and important role in keeping your data (and in some cases your career) safe, but they are also a great way to migrate data from one location to another.
In this post, we’ll look into migration scenario, how to move data from one instance to another and then back again.
Filegroups are an interesting and useful (if not actually all that fun, despite the title) concept within SQL Server. They provide not just a way to group objects like tables together, but also provide a mechanism to help us to speed up the backup, restore, and recovery of the databases. And occasionally, they can even give us a little help with the performance or to migrate data to disks that have more space available.
In this post, focus will be in archiving a table that we no longer need by making a read-only copy of it. In a real-world scenario we’d also consider putting that to a slower disk, if it’s not frequently used, but my demo environment only has a single data disk.
It took me a while to write the first post for 2017, but it has been rather hectic at the office since I moved inside the organization to quite a different role. However I noticed this story a while back and it has been haunting me ever since. Now if you are a DBA then you probably already understand just how important it is to have, not just backups, but valid backups. But what is the difference of a backup and a valid backup?