Imagine a way for IT to always be able to recover its storage to any point in time. That's the Holy Grail of data protection and, at least on the surface, it is what flat backup is all about.
This data backup method is essentially a variation of snapshots. A snapshot copy enables recovery back to the last snapshot point or to any previous version. Granularity of the recovery point is defined by how frequently a snapshot is taken. It might be continuous, where every change is recorded, or there might be intervals of minutes or hours between snapshots.
Snapshot images are different from primary storage. In primary storage, a deletion frees up space, while a change overwrites the existing data. In a snapshot, a deletion or change is flagged in metadata, but the original data itself remains, so any version of an object can be recreated.
Flat backup and snapshots: Pros and cons
Flat backups are great data backup methods when forensic rollbacks are needed, but the backup image grows faster than the primary data. That brings up the issue of where the backup resides.
There is no point in keeping the backup on the same storage as primary data, as was sometimes done in the early days of snapshots. If an organization uses that technique, and the storage appliance takes a hit, both the primary and snapshot will be lost.
It's much better to keep the data on different storage systems; for example, a local version and one in the cloud. "That's just like Amazon's Simple Storage Service," you might say. That's not even close, since the snapshot copy is perpetual storage, while the local image is just today's version of the data. Even so, you are on the right track. Using replication, a couple of local replicas provide fast recovery for computing, while, if the zone goes down, the snapshot enables IT to define a consistent recovery point and move forward in a remote zone.
So far, so good! But what are the flaws in flat backup? These data backup methods use more storage than a typical backup, but the forensic rollback is usually worth it. If copy-on-write is avoided, the performance hit is usually low. And it's a fast, low-overhead process using well-tried code. You don't need those expensive backup packages, since storage vendors usually offer the feature as part of the appliance bundle.
Reconstruction of a data block on the fly is time-consuming. SSD storage will help that in the future, though a shift to appliance-end recovery might be needed, as we've seen with features like compression in all-flash arrays. If a major outage, such as a loss of a primary zone, occurs, building a fresh image of the data from the snapshot copy is best, though it will take some time.
Snapshots are online. This sounds like a plus, but anything online is hackable, and snapshots are no exception. Encryption can prevent data corruption, but anyone wanting to delete a snapshot could have a field day. Protecting against this issue may be simple.
Deletion of a perpetual snapshot copy, the only way to corrupt the contents of a backup, could require an intervention from the cloud service provider, as well as the backup owner, but we aren't that mature yet.
This all suggests that offline backup, such as tape, still has a place within today's data backup methods. Access to data requires a manual or tape library mount, while tape cartridges can be made permanently read-only, thus avoiding the deletion trap. We haven't achieved write-permit tabs in cloud storage yet, but in-house, nontape snapshots might get there.
When to make your world flat
Web servers typically don't need flat backup, but the primary image they are created from does. It could be set to continuous backup, since actual change is relatively rare, and this won't overload the system. This applies to the media server farm, if you have one.
When we get to transactional systems, the game changes for data backup methods. If a transaction tanks because a server died, there are two options. One is to leave the customer to figure it out and try again. The other is to restore the state to where the customer was. The latter is much better. It takes some software finesse to do this, but a flat backup may actually be easier to work with than a replica file, since the backup is time stamped.
Another possibility is to have active computing spread over multiple zones, and to use the backup to recover recent activity. In this case, the backup is essentially a journal log of activity from a recent point in time. In the end, how you do this will depend heavily on your software of choice.
Structured databases are the worst-case flat backup scenario in commercial operations. Data is typically volatile, so the snapshot copy needs to be very frequent, and will use a lot of space. The good news is that these databases are relatively compact, especially when we think of tens of TB in a single SSD. My recommendation is a continuous flat backup for these use cases.
It seems sensible to plant a stake every now and then and sync the snapshot to a consistent level. The way to do this is to make sure all the updates to the backup are processed, then take a clean copy of the new baseline and use it for the next set of flat backups. This baseline would be a good data set to move to an offline backup, as well.
Debunking the top flat backup misunderstandings
The evolution of flat backup technology
Factors that may limit the use of flat backups