It is not even a debate. Not having them will destroy your soul.

I have seen it happen time and time again. Companies going back in time decades, some closing shop, I.T. departments F.U.B.A.R. and peoples lives destroyed. The non-corporate world equivalent is people losing their digital archives of irreplaceable digital memories forever; photographs, videos, etc. Gone. Forever.

On good days your focus could not be further away from thinking about losing data. Things are happening. The world is evolving, your systems are working, and the world is your oyster.

On bad days disks fail, data becomes corrupted, you are under attack by some evil hacker organization. Having a well-thought-out backup plan makes your bad days a nuisance, one undesirable change of plan. But, bad as it is, it will not be a catastrophic failure with dire consequences.

The RAID and other data replication schemes misconception.

Having a system that replicates data against hardware damage of some of the drives is excellent. You can switch to alternative media in failure scenarios and keep your system operational while replacing faulty hardware. It deals with the integrity and failures of your physical layer (hardware).

While under attack or dealing with nasty a bug that slowly (but surely) corrupts your data, it is useless. Automation will ensure that the original and the replicated data are corrupted equally. So you will end up with two perfect clones of the problem and no way to get back to a previous version.

Replication systems are NOT a backup solution. Instead, they address and deal with a specific use case; hardware failure. You need one immutable, point-in-time backup of critical data that you can revert to.

Snapshots and incremental backups

Cloud platforms and Virtual Machines have point-in-time backups called Snapshots. They store the differences between data in two points in time, and you can easily navigate to a previous version of your system.

You can usually automate snapshot creation in ways that fit the ever-changing needs of any particular system. Usually, scheduling is tightly related to the speed at which data changes by design, sometimes tied to logical business cycles. Opening and closing the daily activity in a store, catalog updates, price changes, etc.

The need for offline remote location copies and immutable data

There is no safety whatsoever in having incremental backups if they can be destroyed along with the system they are designed to restore. I have seen ransomware attacks that ended up with backup files held hostage along with everything else. An entire building was destroyed by a fire. These things do happen.

You must keep replicas of the incremental backups, updated regularly on a remote location, preferably offline. This way, you know for sure that it is untouched and ready to be used if the need arises.

Backup restoration is not optional.

I cannot recount how many times I have witnessed puzzled looks on people’s faces when they find out their backups are useless. They simply cannot restore them. When they find out about their predicament, people’s expressions soon turn pale and give way to shock and horror.

You must test the restore procedures (regularly) to ensure they are (and remain) viable and know how long it will take to recover from disaster. That’s where your confidence should come from. Knowing the outcome. Not from the illusion of supposedly having done everything right, only to find out that, in fact, you didn’t.

Do the work. You will get the benefits someday, at the same juncture where most people are hit by drama.

Having backup plan

Effective backup plans vary drastically depending on the systems and data they protect. There is no silver bullet solution to fit all systems and problems.

They must answer the following questions:

• What data needs to be backed up. Some systems have primarily data in transit that can be rebuilt in run-time from the source. There is no point in backing it up. You should have data backed up at its inception already, and the system will populate it on the first run after restoration.
• What system or technology will perform the backup operation?
• Where will backup data be stored?
• What is the procedure to have an offline copy?
• How will it be transported to a secure remote location?
• Are there risks related to data in transit?
• Will backups need to be encrypted?
• How much will backups cost over time?

Timelines:

• How often will backup operations be performed?
• How often are backups validated and restore-tested?
• How long will backups be retained?

People:

• Who has access to backup data?
• Who will have access to the encryption keys that protect backups if encrypted?
• Who is responsible for testing backup restore procedures?
• Who executes backup restoration in real-world scenarios?
• Who is in charge of documenting the processes?

Use and protection:

• What are the emergency procedures?
• What are the specific events the backup strategy is designed for?

Conclusions

Over the years, I have seen too much pain and sorrow over essentially poorly designed or nonexistent backup plans. Don’t be that person that fails. Be better than that.