Flat Backup vs Backup Less, What is the Difference?
Backup/Restore is the Cinderella of the ICT world. Not as glamorous as network security, not as rock-star as leading-edge implementations of cloud technologies, it is still an absolutely vital part of any normal operational routine.
We have moved on from the days of total versus incremental backup strategies, driven mainly by the requirements of the cloud environment, GDPR in Europe, Big Data and the Internet of Things.
The other threat, and it is an increasingly real one, is that of ransomware. Often, the quickest and most secure recovery from a ransomware attack is to go back to bare metal and restore everything from the operating systems upwards from a known clean backup.
We need new thinking and new techniques to meet these new challenges.
Today’s buzzwords and media discussions are around the relative merits of flat backup and backup less strategies. What are they, what’s the difference and how do they address today’s needs?
Back in the day, flat backup was known as in-place backup. Rather than creating a new backup cycle each time a backup is taken, the existing backup file was updated with any changes. That basically is how flat backup works. A master copy of the file is updated with changes which are flagged, providing a snapshot of a data file at any given moment in time. The snapshots can be stored, and if needed exposed to the application needing data to be restored. No format changes, just a data transfer.
There are other benefits to Flat Backups:
- Storage space reductions. With only the current snapshot needed to be saved, that implies a reduction I the backup storage needed for each application. That can translate to cost reductions.
- Recovery Speed. There is now no need to restore an entire file. You need to only recover the latest snapshot, bringing you back up more quickly.
- Better backup strategies. Because flat backups don’t affect application performance, they can be carried out as often as needed, down to every minute for example. This will make for better backups and the probability of a better data recovery if one is needed.
Having said all that though, the usual caveats need to be applied. Keep two copies of the snapshots in different places, one preferably offsite. It is particularly appropriate for cloud backups where a local backup is loaded to the cloud for longer-term storage.
The definition of Backup Less seems to vary according to who is describing it. It seems to be a straightforward definition of a backup strategy where the amount of data to be backed up is sharply reduced.
The core theory seems to be that not everything changes, systems and application executable files very rarely change, so why back them up when they haven’t changed. Take a keypoint backup as a reference point, and thereafter backup only changes to that environment. That can often be carried out in real time.
A backup less strategy is often incorporated in a wider data management strategy where duplication of data is kept to a minimum and consolidation of different data sets is a focus of design strategies.
Hitachi for example have included a backup less approach as part of their overall data management strategy. Their objective is to reduce backup volumes and times and to consolidate data in as efficient a manner as possible to reduce digital media requirements.
They propose a three step strategy:
- Archive.Take a keypoint backup of all systems and data. Tier the data according to value and location;
- Implement a backup less strategy of backing up only those items that have changed; andThey claim a reduction of 30% in data storage by implementing a backup free infrastructure and reviewing capacity usage and efficiency technologies.
- Consolidate data usage and storage.A backup less strategy will require investment in tiered storage – always available storage, spin-up storage for medium latency and off-line storage for the long-term.
Flat or Less
The debate rages on, but as always it will depend on individual circumstances, the amount of data to be backed-up, how quickly it needs to be restored and any legal requirements for retention. What is indisputable is that a comprehensive data backup/recovery programme must be in place.