{"id":5808,"date":"2016-02-03T18:01:52","date_gmt":"2016-02-03T08:01:52","guid":{"rendered":"http:\/\/nsrd.info\/blog\/?p=5808"},"modified":"2018-12-11T10:58:31","modified_gmt":"2018-12-11T00:58:31","slug":"client-load-filesystem-and-database-backups","status":"publish","type":"post","link":"https:\/\/nsrd.info\/blog\/2016\/02\/03\/client-load-filesystem-and-database-backups\/","title":{"rendered":"Client Load: Filesystem and Database Backups"},"content":{"rendered":"

A question I get asked periodically is “can I backup my filesystem and database at the same time?”<\/p>\n

As is often the case, the answer is: “it depends”.<\/p>\n

\"Server<\/a>Or, to put it another way: it depends on what the specific client can handle at the time.<\/p>\n

For the most part, backup products have a fairly basic design requirement: get the data from the source (let’s say “the client”, ignoring options like ProtectPoint for the moment) to the destination (protection storage) as quickly as possible. The faster the better, in fact. So if we want backups done as fast as possible, wouldn’t it make sense to backup the filesystem and any databases on the client at the same time? Well \u2013 the answer is “it depends”, and it comes down to the impact<\/em> it has on the client and the compatibility<\/em> of the client to the process.<\/p>\n

First, let’s consider compatibility \u2013 if both the filesystem and database backup process use the same snapshot mechanism for instance, and only one can have a snapshot operational at any given time, that immediately rules out doing both at once. That’s the most obvious scenario, but the more subtle one almost comes back to the age-old parallelism problem: how fast is too<\/em> fast?<\/p>\n

If we’re simultaneously conducting a complete filesystem read (say, in the case of a full backup) and<\/em> simultaneously reading an entire database and<\/em> the database and filesystem we’re reading from both reside on the same physical LUN, there is the potential the two reads will be counter-productive: if the underlying physical LUN is in fact a single disk, you’re practically guaranteed that’s the case, for instance. We wouldn’t normally want RAID-less storage for pretty much anything in production, but just slipping RAID into the equation doesn’t guarantee we can achieve both reads simultaneously without impact to the client \u2013 particularly if the client is already doing other things<\/em>. Production things<\/em>.<\/p>\n

Virtualisation doesn’t write a blank cheque, either; image level backup with databases in the image<\/em> are a bit of a holy grail in the backup industry but even in those situations where it may be supported, it’s not supported for every database type<\/em>; so it’s still more common than not to see situations where you have virtual\/image level backups for the guest for crash consistency on the file and operating system components, and then an in-guest database agent running for that true guaranteed database recoverability. Do you want a database and image based backup happening at the same time? Your hypervisor is furiously reading the image file while<\/em> the in-guest agent is furiously reading the database.<\/p>\n

In each case that’s just at a per client level. Zooming out for a bit in a datacentre with hundreds or thousands of hosts all accessing shared storage via shared networking, usually via shared compute resources as well, how long is a piece of string<\/em> becomes a exponentially increasing question as the number of shared resources and items sharing those resources start to come into play.<\/p>\n

Unless you have an overflow of compute resources and SSD offering more IO than your systems can ever need, can I backup my filesystem and databases at the same time<\/em> is very much a non-trivial question. In fact, it becomes a bit of an art, as does all performance tuning. So rather than directly answering the question, I’ll make a few suggestions to be considered along the way as you<\/em> answer the question for your environment:<\/p>\n