Instead, I’m going to suggest there’s actually at least ten factors that go into making up a successful backup, and explain why each one of them is important.<\/p>\n This is the most simple explanation of a successful backup. One that literally finishes successfully. It makes sense, and it should be a given. If a backup fails to transfer the data it is meant to transfer during the process, it’s obviously not successful.<\/p>\n Now, there’s a caveat here, something I need to cover off. Sometimes you might encounter situations where a backup completes successfully but<\/em> triggers or produces a spurious error as it finishes. I.e., you’re told it failed, but it actually succeeded. Is that a successful backup? No. Not in a useful way, because it’s encouraging you to ignore errors or demanding manual cross-checking.<\/p>\n Sometimes warnings will be thrown during a backup. It could be that a file had to be re-read, or a file was opened at the time of backup (e.g., on a Unix\/Linux system) and could only be partially read.<\/p>\n Some warnings are acceptable, some aren’t. Some warnings that are acceptable on one system may not be acceptable on another. Take for instance, log files. On a lot of systems, if a log file is being actively written to when the backup is running, it could be that the warning of an incomplete capture of the file is acceptable. If the host is a security logging system and compliance\/auditing requirements dictate all security logs are to be recoverable, an open-file warning won’t<\/em> be acceptable.<\/p>\n I honestly can’t say the number of times over the years I’ve heard of situations where a backup was assumed<\/em> to have been running successfully, then when a recovery is required there’s a flurry of activity to determine why the recovery can’t work … only to find the backup hadn’t been completing successfully for days, weeks, or even months. I really have dealt with support cases in the past where critical data that had<\/em> to be recovered was unrecoverable due to a recurring backup failure \u2013 and one that had been going on, being reported in logs and completion notifications, day-in, day-out, for months<\/em>.<\/p>\n So, a successful backup is also a backup here the end-state is captured and reported on. The logical result is that if the backup does<\/em> fail, someone knows about it and is able to choose an action for it.<\/p>\n When I first started dealing with NetWorker, that meant checking the savegroup completion reports in the GUI. As I learnt more about the importance of automation, and systems scaled (my system administration team had a rule: “if you have to do it more than once, automate it”), I built parsers to automatically interpret savegroup completion results and provide emails that would highlight backup failures.<\/p>\n As an environment scales further, automated parsing needs to scale as well \u2013 hence the necessity of products like Data Protection Advisor, where you not only get simple dashboards for overnight success ratios with drill-downs, root cause analysis, and all the way up to SLA adherence reports and beyond.<\/p>\n In short, a backup needs to be reported on to be successful.<\/p>\n A backup exists for one reason alone \u2013 to allow the retrieval and reconstruction of data in the event of loss or corruption. If the way in which the backup is run doesn’t allow for a successful recovery, then the backup should not be counted as a successful backup, either.<\/p>\n Open files are a good example of this \u2013 particularly if we move into the realm of databases. For instance, on a regular Linux filesystem (e.g., XFS or EXT4), it would be perfectly possible to configure a filesystem backup of an Oracle server. No database plugin, no communication with RMAN, just a rolling sweep of the filesystem, writing all content encountered to the backup device(s).<\/p>\n But it wouldn’t be recoverable. It’s a crash-consistent backup, not an application-consistent backup. So, a successful backup must be a backup that can be successfully recovered from, too.<\/p>\n Ideally, every backup should get a redundant copy \u2013 a clone. Practically, this may not always be the case. The business may decide, for instance, that ‘bronze’ tiered backups \u2013 say, of dev\/test systems, do not require backup replication. Ultimately this becomes a risk decision for the business and so long as the right role(s) have signed off against the risk, and it’s deemed to be a legally acceptable risk, then there may not be copies made of specific types of backups.<\/p>\n But for the vast majority of businesses, there will<\/em> be backups for which there is a legal\/compliance requirement for backup redundancy. As I’ve said before, your backups should not be a single point of failure within your data protection environment.<\/p>\n So, if a backup succeeds but its redundant copy fails, the backup should, to a degree, be considered to have failed. This doesn’t mean you have to necessarily do<\/em> the backup again, but if redundancy is required, it means you do<\/em> have to make sure the copy gets made. That then hearkens back to requirement three \u2013 the end state has to be captured and reported on. If you’re not capturing\/reporting on end-state, it means you won’t be aware if the clone of the backup has succeeded or not.<\/p>\n You have a flight to catch at 9am. Because of heavy traffic, you don’t arrive at the airport until 1pm. Did you successfully<\/em> make it to the airport?<\/p>\n It’s the same with backups. If, for compliance reasons you’re required to have backups complete within 8 hours, but they take 16 to run, have they successfully completed? They might exit without an error condition, but if SLAs have been breached, or legal requirements have not been met, it technically doesn’t matter that they finished without error. The time<\/em> it took them to exit was, in fact, the error condition. Saying it’s a successful backup at this point is sophistry.<\/p>\n This can happen one of two different ways. The first is actually a special condition of rule six \u2013 even if there are no compliance considerations, if a backup meant to run once a day takes longer than 24 hours to complete, then by extension, it’s going to prevent the next backup from running. This becomes a double failure \u2013 not only does the next backup run, but the next backup doesn’t run because the earlier backup is blocking it.<\/p>\n The second way is not necessarily related to backup timing \u2013 this is where a backup completes, but it leaves system in state that prevents next backup from running. This isn’t necessarily a common thing, but I have seen situations where for whatever reason, the way<\/em> a backup finished prevented the next backup from running. Again, that becomes a double failure.<\/p>\n There’s two effective categories of backups \u2013 those that are started automatically, and those that are started manually. A backup may in fact be started manually (e.g., in the case of an ad-hoc backup), but should still be able to complete without manual intervention.<\/p>\n As soon as manual intervention is required in the backup process, there’s a much greater risk of the backup not completing successfully, or within the required time-frame. This is, effectively, about designing the backup environment to reduce risk by eliminating human intervention. Think of it as one step removed from the classic challenge that if your backups are required but don’t start without human intervention, they likely won’t run. (A common problem with ‘strategies’ around laptop\/desktop self-backup requirements.)<\/p>\n There can be workarounds for this – for example, if you need to trigger a database dump as part of the backup process (e.g., for a database without a plugin), then it could be a password needs to be entered, and the dump tool only accepts passwords interactively. Rather than having someone actually manually enter the password, the dump command could instead be automated with tools such as Expect.<\/p>\n (We’re in the home stretch now.)<\/p>\n A backup should be as light-touch as possible. The best example perhaps of a ‘heavy touch’ backup is a cold database backup. That’s where the database is shutdown for the duration of the backup, and it’s a perfect situation of a backup directly impacting\/impeding access to the data being protected. Sometimes it’s more subtle though \u2013 high performance systems may have limited IO and system resources to handle the steaming of a backup, for instance. If system performance is degraded by the backup, then it should be considered the case the backup is unsuccessful.<\/p>\n I liken this to uptime<\/em> vs availability<\/em>. A server might be up, but if the performance of the system is so poor that users consider the service offered by the system, it’s not usable. That’s where, for instance, systems like ProtectPoint<\/a> can be so important \u2013 in high performance systems it’s not just about getting a high speed backup, but limiting the load of the database server during the backup process.<\/p>\n Of course, there are ad-hoc backups that might only ever need to be run once, or backups that you may never need to run again (e.g., pre-decommissioning backup).<\/p>\n The vast majority of backups within an environment though will be repeated daily. Ideally, the result of each backup should be predictably repeatable. If the backup succeeds today, and there’s absolutely no changes to the systems or environment, for instance, then it should be reasonable to expect the backup will succeed tomorrow. That doesn’t ameliorate the requirement for end-state capturing and reporting; it does<\/em> mean though that the backup results shouldn’t effectively be random.<\/p>\n It’s easy to understand why the simplest answer (“it completes without error”) can be so easily assumed to be the whole answer to “what constitutes a successful backup?” There’s no doubt it forms part of the answer, but if we think beyond the basics, there are definitely a few other contributing factors to achieving really<\/em> successful backups.<\/p>\n Consistency, impact, recovery usefulness and timeliness, as well as all the other rules outlined above also come into how we can define a truly successful backup. And remember, it’s not about making more work for us, it’s about preventing future problems.<\/p>\n![\"Bullseye\"](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2017\/05\/bigStock-Bullseye.jpg\")
<\/a><\/p>\nThe Rules<\/h2>\n
One \u2013 It finishes without a failure<\/h3>\n
Two \u2013 Any warnings produced are acceptable<\/h3>\n
Three \u2013 The end-state is captured and reported on<\/h3>\n
Four \u2013 The backup method allows for a successful recovery<\/h3>\n
Five \u2013 If an off-site\/redundant copy is required, it is successfully performed<\/h3>\n
Six \u2013 The backup completes within the required timeframe<\/h3>\n
Seven \u2013 The backup does not prevent the next backup from running<\/h3>\n
Eight \u2013 It does not require manual intervention to complete<\/h3>\n
Nine \u2013 It does not unduly impact access to the data it is protecting<\/h3>\n
Ten \u2013 It is predictably repeatable<\/h3>\n
In Summary<\/h2>\n
\n