Author: John Miller, III
Date: September 30, 2019
Originally published on the Fauna blog.

A developer likes solving large and complex issues for their customers by writing flashy programs which interact with the desktop, web, mobile, or other devices. To accomplish this, the developer requires a solid data platform to store and retrieve data. The better aligned the data platform is with the developers’ requirements, the less mundane tasks the developer has to build and the more time they can spend writing exciting code for their customers.

An example of a data platform requirement can be transactional consistency. Some databases adhere to eventual consistency, while FaunaDB has globally consistent transactions. While both can be used, if the developer has a requirement of globally consistent data and they choose an eventually consistent database as part of their data platform, the developer will be building an excessive amount of logic into the application. If an efficient data platform was chosen, the developer could spend more time on solving the customer’s application needs and a flashier application.

In this article I will discuss some of the data protection issues related to data loss and how a developer can avoid or recover from them. While transactions play a large part in this I am going to focus on other types of data loss, such as catastrophic or schema loss.

Catastrophic Failures

One of the first data safety issues to explore is a catastrophic failure of a site, single business provider, geographical region. With today’s availability standards this is very important but often forgotten. FaunaDB keeps multiple live copies of the data on several geographically dispersed replicas on different cloud providers (see map below). Due to the FaunaDB’s ACID transactional consistency model (see Jepsen) the application can utilize any or all sites and achieve the same consistent results. In addition to the multiple copies of live data, FaunaDB has a built-in traditional backup to offsite storage. This allows FaunaDB to store the data and transaction logs in an encrypted offsite location. These files can be used to reconstruct FaunaDB entire cluster to the current point in time in case of a major catastrophic failure.

Accidentally Deleted Document

Another issue which often affects developers is the ability to restore accidentally removed or updated documents. In FaunaDB, this is simple because of FaunaDB’s temporal capabilities. This restoration of data can be accomplished in seconds utilizing only the FaunaDB FQL language and appropriate permissions. Let outline the three simple steps to Un-Delete your document in seconds:

1. You need to identify the refs to the document(s) which were affected.
2. List the events for each affected document locating the timestamp for the most recent remove event:
3. Remove the delete event for the document by providing the document reference and the timestamp for the delete event:

While there are limits on how old the data is that can be undeleted, this is controlled by the developer when creating a collection (i.e. table) and defaults to 30 days. In many other databases the developer often has to contact a DBA to do some type of restore from offline media.

Accidentally Deleted Collection or Database

The accidental dropping of database or collection is another one of the many actions developers like to safeguard against. While the same methodology of modifying the events of the database or collection could be applied to instantaneously recover a database or collection, the developer currently does not have access to internal schema events. Fauna is currently planning to release a simple way to modify these events to allow the undeleting of databases and collections. In this way a developer will be able to correct the accidental dropping in seconds instead of hours or days.

Data Security

Data loss can also occur because of theft of data. First and foremost, all data, in monition on a public network or at rest on disk drives, is encrypted. FaunaDB has an elaborate security model intended for the cloud which can be read about in a previous blog post.

In addition, FaunaDB has a new security feature called Attribute-Based Access Control (ABAC). This is an alternative to an all-or-nothing security model and is commonly used in applications to restrict access to specific data based on the user’s role. ABAC is an extension of role-based access control (RBAC), where users are assigned roles that grant them specific privileges. The benefit of ABAC is that privileges can be dynamically determined based on attributes of the user, the documents to be accessed or modified, or context during a transaction (e.g. time of day).

Conclusion

While data loss is something that no one ever wants to experience, we all need to prepare for the event and have a plan for the various scenarios. Fauna’s cloud solution builds into the base architecture encryption and the ability to recover from catastrophic system failures. FaunaDB’s temporal nature to provide it users with an impressive ability to instantaneously recover data which might have been accidentally removed. Preparing for a data loss event is like having life insurance: you never want to use it, but your family is glad that you have it!