![]() ![]() The business may decide, for instance, that ‘bronze’ tiered backups – say, of dev/test systems, do not require backup replication. Practically, this may not always be the case. Ideally, every backup should get a redundant copy – a clone. Five – If an off-site/redundant copy is required, it is successfully performed So, a successful backup must be a backup that can be successfully recovered from, too. It’s a crash-consistent backup, not an application-consistent backup. No database plugin, no communication with RMAN, just a rolling sweep of the filesystem, writing all content encountered to the backup device(s).īut it wouldn’t be recoverable. 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. Open files are a good example of this – particularly if we move into the realm of databases. 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. Four – The backup method allows for a successful recoveryĪ backup exists for one reason alone – to allow the retrieval and reconstruction of data in the event of loss or corruption. In short, a backup needs to be reported on to be successful. 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.Īs an environment scales further, automated parsing needs to scale as well – 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. When I first started dealing with NetWorker, that meant checking the savegroup completion reports in the GUI. The logical result is that if the backup does fail, someone knows about it and is able to choose an action for it. So, a successful backup is also a backup here the end-state is captured and reported on. I honestly can’t say the number of times over the years I’ve heard of situations where a backup was assumed 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 to be recovered was unrecoverable due to a recurring backup failure – and one that had been going on, being reported in logs and completion notifications, day-in, day-out, for months. Three – The end-state is captured and reported on 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 be acceptable. 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. Some warnings that are acceptable on one system may not be acceptable on another. Take for instance, log files. Some warnings are acceptable, some aren’t. 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. Sometimes warnings will be thrown during a backup. Two – Any warnings produced are acceptable Not in a useful way, because it’s encouraging you to ignore errors or demanding manual cross-checking. I.e., you’re told it failed, but it actually succeeded. Sometimes you might encounter situations where a backup completes successfully but triggers or produces a spurious error as it finishes. Now, there’s a caveat here, something I need to cover off. If a backup fails to transfer the data it is meant to transfer during the process, it’s obviously not successful. ![]() It makes sense, and it should be a given. One that literally finishes successfully. This is the most simple explanation of a successful backup. The Rules One – It finishes without a failure ![]() 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. On the surface, you might suggest the answer is simply “a backup that completes without error”, and that’s part of the answer, but it’s not the complete answer. A seemingly straight-forward question, what constitutes a successful backup may not engender the same response from everyone you ask. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |