{"id":5826,"date":"2016-03-09T18:57:16","date_gmt":"2016-03-09T08:57:16","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5826"},"modified":"2018-12-11T10:57:51","modified_gmt":"2018-12-11T00:57:51","slug":"who-should-handle-your-database-backups","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2016\/03\/09\/who-should-handle-your-database-backups\/","title":{"rendered":"Who should handle your database backups?"},"content":{"rendered":"

I’ve been working with backups for 20 years, and if there’s been one constant in 20 years I’d say that application owners (i.e., DBAs) have traditionally been reluctant to have other people (i.e., backup administrators) in control of the backup process for their databases. This leads to some environments where the DBAs maintain control of their backups, and others where the backup administrators maintain control of the database backups.<\/p>\n

\"Junction\"<\/a><\/p>\n

So the question that many people end up asking is: which way is the right way? The answer, in reality is a little fuzzy, or, it depends<\/em>.<\/p>\n

When we were primarily backing up to tape, there was a strong argument for backup administrators to be in control of the process. Tape drives were a rare commodity needing to be used by a plethora of systems in a backup environment, and with big demands placed on them. The sensible approach was to fold all database backups into a common backup scheduling system so resources could be apportioned efficiently and fairly.<\/p>\n

\"DB<\/a>
Traditional backups to tape via a backup server<\/figcaption><\/figure>\n

With limited tape resources and a variety of systems to protect, backup administrators needed to exert reasonably strong controls over what backed up when, and so in a number of organisations it was common to have database backups controlled within the backup product (e.g., NetWorker), with scheduling negotiated between the backup and database administrators. Where such processes have been established, they often continue \u2013 backups are, of course, a reasonably habitual process (and for good cause).<\/p>\n

For some businesses though, DBAs might feel there was not enough control over the backup process \u2013 which might be agreed with based on the mission criticality of the applications running on top of the database, or because of the perceived licensing costs associated with using a plugin or module from the backup product to backup the database. So in these situations if a tape library or drives weren’t allocated directly to the database, the “dump and sweep” approach became quite common, viz.:<\/p>\n

\"Dump<\/a>
Dump and Sweep<\/figcaption><\/figure>\n

One of the most pervasive results of the “dump and sweep” methodology however is the amount of primary storage it uses. Due to it being much faster than tape, database administrators would often get significantly larger areas of storage \u2013 particularly as storage became cheaper \u2013 to conduct their dumps to. Instead of one or two days, it became increasingly common to have anywhere from 3-5 days of database dumps sitting on primary storage being swept up nightly by a filesystem backup agent.<\/p>\n

Dump and sweep of course poses problems: in addition to needing large amounts of primary storage, the first backup for the database is on-platform<\/em> \u2013 there’s no physical separation. That means the timing of getting the database backup completed before<\/em> the filesystem sweep starts is critical. However, the timing for the dump is controlled by the DBA and dependent on the database load and<\/em> the size of the database, whereas the timing of the filesystem backup is controlled by the backup administrator. This would see many environments spring up where over time the database grew to a size it wouldn’t get an off-platform<\/em> backup for 24 hours \u2013 until the next filesystem backup happened. (E.g., a dump originally taking an hour to complete would be started at 19:00. The backup administrators would start the filesystem backup at 20:30, but over time the database backups would grow and wouldn’t complete until say, 21:00. Net result could be a partial or failed backup of the dump files the first night, with the second<\/em> night being the first successful backup of the dump.)<\/p>\n

Over time backup to disk entered popularity to overcome the overnight operational challenges of tape, then grew, and eventually the market has expanded to include deduplication storage, purpose built backup appliances and even when I’d normally consider to be integrated data protection appliances \u2013 ones where the intelligence (e.g., deduplication functionality) is extended out from the appliance to the individual systems being protected. That’s what we get, for instance, with Data Domain: the Boost functionality embedded in APIs on the client systems leveraging distributed segment processing to have everything being backed up participate in its own deduplication. The net result is one that scales better than the traditional 3-tier “client\/server\/{media server|storage node}” environment, because we’re scaling where it matters: out<\/em> at the hosts being protected and up<\/em> at protection storage, rather than adding a series of servers in the middle to manage bottlenecks. (I.e., we remove the bottlenecks.<\/a>)<\/p>\n

Even as large percentages of businesses switched to deduplicated storage \u2013 Data Domains mostly from a NetWorker perspective \u2013 and had the capability of leveraging distributed deduplication processes to speed up the backups, that legacy “dump and sweep” approach, if it had been in the business, often remained in the business.<\/p>\n

We’re far enough into this now that I can revisit the two key schools of thought within data protection:<\/p>\n