Yet, there’s improvements that can be made to data protection attitudes within many organisations, and I wanted to outline things that can still be done incorrectly within organisations in relation to backup and recovery.<\/p>\n
Many businesses now clone, duplicate or replicate their backups \u2013 but not all of them.<\/p>\n What’s more, occasionally businesses will still design backup to disk strategies around non-RAID protected drives. This may seem like an excellent means of storage capacity optimisation, but it leaves a gaping hole in the data protection process for a business, and can result in catastrophic data loss.<\/p>\n Assembling a data protection strategy that involves unprotected backups is like configuring primary production storage without RAID or some other form of redundancy. Sure, technically it works … but you only need one error and suddenly your life is full of chaos.<\/p>\n The old superstition was that backups were a waste of money \u2013 we do them every day, sometimes more frequently, and hope that we never have to recover from them. That’s no more a waste of money than an insurance policy that doesn’t get claimed on is.<\/p>\n However, what is<\/strong> a waste of money so much of the time is a backup strategy that’s unaligned to actual business requirements. Common mistakes in this area include:<\/p>\n To put it bluntly, many DBAs get quite precious about the data they’re tasked with administering and protecting. And thats entirely fair, too \u2013 structured data often represents a significant percentage of mission critical functionality within businesses.<\/p>\n However, there’s nothing special<\/em> about databases any more when it comes to data protection. They should<\/em> be integrated into the data protection strategy. When they’re not, bad things can happen, such as:<\/p>\n When you think about it, practically all<\/em> data within an environment is special in some way or another. Mail data is special. Filesystem data is special. Archive data is special. Yet, in practically no organisation will administrators of those specific systems get such free reign over the data protection activities<\/em>, keeping them silo’d off from the rest of the organisation.<\/p>\n Backup systems are rarely static within an organisation. As primary data grows, so to does the backup system. As archive grows, the impact on the backup system can be a little more subtle, but there remains an impact.<\/p>\n Some of the worst mistakes I’ve seen made in backup systems planning is assuming what is bought today<\/em> for backup will be equally suitable for next year<\/em> or a period of 3-5 years from now.<\/p>\n Growth must not only be forecast for long-term planning within a backup environment, but regularly reassessed. It’s not possible, after all, to assume a linear growth pattern will remain constantly accurate; there will be spikes and troughs caused by new projects or business initiatives and decommissioning of systems.<\/p>\n If you don’t have a zero error policy in place within your organisation for backups, you don’t actually have a backup system<\/em>. You’ve just got a collection of backups that may or may not have worked.<\/p>\n Zero error policies rigorously and reliably capture failures within the environment and maintain a structure for ensuring they are resolved, catalogued and documented for future reference.<\/p>\n Backups are not<\/em> in themselves disaster recovery strategies; their processes without a doubt play into disaster recovery planning and a fairly important part, too.<\/p>\n But having a backup system in place doesn’t mean you’ve got a disaster recovery strategy in place.<\/p>\n The technology side of disaster recovery \u2013 particularly when we extend to full business continuity \u2013 doesn’t even approach half<\/em> of what’s involved in disaster recovery.<\/p>\n One could argue this is an extension of growth and capacity forecasting, but in reality it’s more the case that these two issues will usually have a degree of overlap.<\/p>\n As this is typically exemplified by organisations that don’t have formalised procedures, the easiest way to ensure new systems deployment allows for inclusion into backup strategies is to have build forms \u2013 where staff would not only request storage, RAM and user access, but also backup.<\/p>\n To put it quite simply – no new system should be deployed within an organisation without at least consideration<\/em> for backup.<\/p>\n Particularly in environments that still have a lot of tape (either legacy or active), a backup system will have more physical components than just about everything else in the datacentre put together \u2013 i.e., all the media.<\/p>\n In such scenarios, a regrettably common mistake is a lack of policies for dealing with cartridges as they age. In particular:<\/p>\n These tasks aren’t particularly enjoyable \u2013 there’s no doubt about that. However, they can be reasonably automated, and failure to do so can cause headaches for administrators down the road. Sometimes I suspect these policies aren’t enacted because in many organisations they represent a timeframe beyond the service time of the backup administrator. However, even if this is<\/em> the case, it’s not an excuse, and in fact should point to a requirement quite the opposite.<\/p>\n Failure to track media ageing is probably akin to deciding not to ever service your car. For a while, you’ll get away with it. As time goes on, you’re likely to run into bigger and bigger problems until something goes horribly wrong.<\/p>\n![\"\"](\"https:\/\/nsrd.info\/blog\/wp-content\/uploads\/2012\/03\/10.jpg\" "\\"10\\"")
<\/a>Backups aren’t protected<\/strong><\/p>\n<\/a>Backups not aligned to business requirements<\/strong><\/p>\n\n
<\/a>Databases insufficiently integrated into the backup strategy<\/strong><\/p>\n\n
<\/a>Growth not forecast<\/strong><\/p>\n<\/a>Zero error policies aren’t implemented<\/strong><\/p>\n<\/a>Backups seen as a substitute for Disaster Recovery<\/strong><\/p>\n<\/a>New systems deployment not factoring in backups<\/strong><\/p>\n<\/a>No formalised media ageing policies<\/strong><\/p>\n\n