Until containers support persistent storage that can be easily backed-up, their use will be limited to test and development. This is not to say that containers can’t bring significant value to the test and development world. It’s just that they can also bring significant value to the production world if we can solve the persistent storage problem.
Microsoft’s Container Fumble
Microsoft released Windows Server 2016 with native container support, and support for Pro and Enterprise editions of Windows 10. Given the gradual plans for enterprise adoption of Windows Server 2016 seen in industry surveys, it seems clear that Microsoft is focused on giving users a reason to upgrade.
Considering the key role that SQL Server plays in enterprise applications, it’s difficult to understand why six months following the Windows Server 2016 release that Microsoft supports only SQL Server 2016 Express and an evaluation version of SQL Server vNext (Microsoft’s upcoming cross-platform version of SQL Server). Microsoft’s website says “vNext is intended as a test version only. Production deployments are not supported.” In addition, Microsoft has not yet announced how they are going to license SQL Server for containers. To add insult to injury, Microsoft containers require a rebuild following Windows updates. Ouch.
It would be much nicer to run containers on any recent version of Windows, such as Windows 8 and 10, Windows Server 2012 and Windows Server 2016. And it’s hard to imagine a credible enterprise strategy that doesn’t feature broad support of SQL Server. And requiring a container rebuild after Windows updates is completely unacceptable.
But the real problem with containers in production use is data. Yes, you can mount a Docker volume to a Docker container and the volume will persist outside of the existence of the container. That’s not the problem. The problem is: how do you backup a database that is attached to a container?
The Containerized SQL Server Protection Challenge
Whenever a container-related company briefs us, I ask them how the product supports backup. I typically get one of two answers, neither of which I like. The first answer is that the database is accessible like any other database via IP, and you can use that connection to dump the database to some other storage prior to backing up that storage. This is how we backed up databases – 20 years ago. Proper database backup design now dictates some sort of agent that automatically talks to the database and backs up its data directly to the backup storage. While dumping a database to a file that gets backed up isn’t horrible, but it’s far from ideal.
The other answer I hear is to shut down the container and backup the Docker volume. This method could be built into a backup system, but requires shutting down the database and that is also far from ideal. We need a way to backup a running database attached to a container without having to dump it to separate storage.
The WinDocks Recovery
WinDocks is the first vendor to brief us that says it has a solution for the issues outlined above. Its version of Docker containers supports all editions of Windows 8 and Windows 10, Windows Server 2012, and Windows Server 2016. In addition, WinDocks supports all editions of SQL Server 2008 onward.
The WinDocks container design is an application level service, and enables Windows updates to the container host without requiring rebuilds of containers and images. WinDocks SQL Server containers are based on a host default SQL Server instance, and delivers SQL Server named “container” instances. This approach allows customers to use existing systems, with current licenses, and realize significant license cost savings. WinDocks shared that a typical development or QA team uses a single shared server or VM, with each member working with containers. WinDocks claims the result is an average 5-fold reduction in use of VMs.
But when I got truly excited was when the company answered the backup question. It turns out that WinDocks SQL Server containers appear to Windows just like any other SQL Server instances. (This is not true for the Microsoft implementation of Docker.) This is important because it means that WinDocks will interface with Windows Volume Shadow Services (VSS). Whether WinDocks is running in a VM or on a physical server, any modern backup software is going to interface with VSS prior to backing up that VM or server. VSS will identify the SQL Server instances running in containers and will tell each instance to do the appropriate thing prior to taking a snapshot. (Each application has its own pre-snapshot procedure, but what SQL Server does prior to a snapshot is to momentarily pause all writes to the database.) This means we can backup running WinDocks SQL Server containers, with current backup systems, without dumping to a separate file and without shutting down the container. Eureka!
Containers are going to play an ever-increasing role in modern data centers. Implementations such as WinDocks make it easier to use containers in production, on any version of Windows and SQL Server, with support for current backup systems, should be very popular. It appears to us that WinDocks fulfills their claim of being “the practical Windows container.” Unfortunately, the Microsoft implementation of Docker doesn’t seem to yet understand this little issue. Maybe WinDocks can start a trend and containers will get easier to backup.