Backups
Overview
Fauna’s database service employs data redundancy, where three or more copies of a database’s schema and documents exist at any given time.
Data redundancy is Region Group specific. For example, data in the EU Region Group is not replicated to any other Region Group.
However, data redundancy cannot protect against operator errors, logic bugs, and other operational effects that cause unexpected behavior. To address these concerns, Fauna provides a backup/restore/copy feature.
| To configure backups, or to perform restores or copies, you must be on a Business or Team plan, and you must have owner or admin privileges in your account. |
How backups work
Each day, Fauna produces a snapshot for each database, that has backups enabled, at a predetermined time (at or near 6am UTC). Each snapshot contains all of the schema and documents, including child databases that were available at the instant that the snapshot was produced.
Snapshot attributes
Snapshots have these attributes:
-
Each snapshot contains all of a database’s schema and documents, including child databases, GraphQL schema, collections, credentials, functions, indexes, keys, tokens, and external authentication configuration.
-
Snapshots are stored internally, within Fauna’s service but outside of the main database, and are not downloadable.
-
Snapshot storage exists within the same Region Group as the original database.
-
Snapshots are created daily, and do not affect any previously-created snapshots.
-
Each snapshot should be available at about the same time each day, varying by plus or minus 30 minutes.
-
Snapshots are, by default, retained for 30 days. You can choose a custom retention period:
-
30 days
-
90 days
-
180 days
-
365 days
-
indefinitely
-
-
Expired snapshots are removed within 24 hours of the expiration of the retention period.
-
Snapshots exist at the account level and are retained even if the original database has been deleted, or if the database’s backups have been disabled. This is convenient in situations where you need to recover a database which you may have deleted erroneously.
| Each snapshot incurs creation and retention charges. See Backups to learn more. |
How snapshots can be used
Once a per-database snapshot is available, you can start restoring the snapshot to the associated database (resetting the database to the point in time when the snapshot was created), or copying the snapshot’s contents to a new database. For copies, the new database can be in a different Region Group than the original database.
When a "restore" is complete, the affected database contains all of the schema and documents that existed when the snapshot was created, and keys, tokens, and external authentication continues to work.
When a "copy" is complete, the target database contains all of the schema and documents that existed when the snapshot was created, but keys, tokens, and external authentication are not copied and no longer work: the secrets and JWT tokens for the original database continue to work with the original database, not the copy.
| The time required to process a restore or copy operation depends mostly on the size of your database. For a copy to a different Region Group, the time may increase due to geographic distance. |
| While a restore or copy operation is under way, the target database is inaccessible. Queries that attempt to access the target database fail. Once the operation is complete, the target database becomes available. |
Make backups (aka snapshots)
After you login to the Fauna Dashboard, you can view a database’s settings (where backups are enabled/disabled) in several ways:
-
From the Home page, or a database overview page where child databases exist, scroll to find the database that you’d like to backup, and click its gear icon (
). -
From the Home page, or a database overview page where child databases exist, scroll to find the database that you’d like to backup, click its name, then click Settings.
-
From a database overview page, click Backup in the left sidebar.
-
From the account dropdown at the top right, click Settings to view the settings overview, then click Backups in the left sidebar. Scroll to find the database that you’d like to backup, expanding the list of databases when child database exist, then click its gear icon (
).
Once the database’s settings are displayed:
Click the Enable checkbox to enable backups, which displays the retention selector, and provides a list of available snapshots, if any:
Optionally, choose a different retention period. The default retention is 1 month (30 days).
Click SAVE to save the backup settings.
When backups are enabled, per-database snapshots are created once per day at a predetermined time (at or near 6am UTC).
Review backup configuration and snapshot availability
After you login to the Fauna Dashboard, you can review which databases have backups enabled, either for all databases/snapshots, or per-database.
All backups and snapshots
From the account dropdown at the top right, click Settings to view the settings overview, then click Backups in the left sidebar. The Backup overview screen is displayed:
The overview shows all databases, their Region Groups, whether backups
are enabled or not, the timestamp of the most recent snapshot (if any),
plus the schedule, and retention period. Click the gear icon
() beside any database to display its configuration
panel, and its available snapshots.
Click the Databases selector above the table and select Snapshots to switch the view to a list of snapshots across all databases in your account:
The page shows the list of snapshots (if any), including their creation date, number of days before snapshot expiry, snapshot size in gigabytes (hover over a size to see a more detailed size).
Per database
View the Dashboard’s home page, click a database in the list, then click Backups in the left navigation pane. The Backups page for the selected database is displayed:
The page shows the list of snapshots (if any) for the current database, including the their creation date, number of days before snapshot expiry, snapshot size in gigabytes (hover over a size to a more detailed size).
Restore from a snapshot
You can restore a database from a snapshot, which fully overwrites the original database and restores all of the databases schema and documents, including child databases, keys, tokens, and external authentication configuration.
A database restore is useful to "reset" a database that has suffered unintentional or unexpected changes that would otherwise be difficult to recover from.
Be aware that:
-
Any child databases which have been added since the snapshot was created are removed during the restore process.
-
The name of any child database which has been renamed since the snapshot was created is overwritten with the name recorded in the snapshot.
You can view the list of snapshots by clicking the gear icon
() beside any database to display its configuration:
If at least one snapshot exists, you can restore from that snapshot to
its associated database by clicking the restore icon
(
) beside any snapshot timestamp. The Restore Data
panel is displayed:
Check the checkbox I understand this database will be unavailable until the restore process is completed, then click BEGIN RESTORE. The snapshot restoration process should begin momentarily.
Once the restoration process begins, the database associated with the snapshot becomes unavailable to all queries until the snapshot process is complete or fails.
A badge appears beside the database’s name indicating the current status of the restoration:
-
(Restore: Pending): the restoration process is starting. -
(Restore: InProgress): the restoration process is underway.
When the restoration process completes successfully, the database access is reinstated. Should the restoration process fail, for any reason, the original database (prior to the restore) continues to exist. Access to the database should be restored immediately, but can sometimes be delayed.
Copy from a snapshot
You can create a new database populated with the schema and documents from a snapshot by performing a copy. The copy includes any child databases stored in the snapshot, but does not include keys, tokens, or external authentication configuration.
A database copy is useful for setting up development, test, or staging environments with data copied from your production database. It is also useful for making documents available in a different Region Group. Creating a copy has no affect on the original database.
Be aware that a database created from a snapshot:
-
Has none of the keys or tokens from the original database. You have to create new keys or tokens because the originals refer to original database.
You can view the list of snapshots by clicking the gear icon
() beside any database to display its configuration:
If at least one snapshot exists, you can copy from that snapshot to a
new database by clicking the restore icon
(
) beside any snapshot timestamp. The Copy Data
panel is displayed:
Choose the intended "destination" for the new database. That can be one of:
-
Root: creates the new database in the root of your account.
-
One of the listed databases: creates the new database as a child of the selected database. When you choose an existing database, the new database is stored in the selected database’s Region Group.
When the Root database is selected, you also can select the Region Group where the new database should be stored.
You can give the new database a name. By default, the new name is
Copy_ plus the name of the original database that was used to create
the snapshot.
Check the checkbox I understand the destination database will be unavailable until the data copy is completed, then click BEGIN COPY. The snapshot copy process begins.
The amount of time that a copy takes depends on when the process can begin, and the size of the snapshot. Copy tasks are processed in a queue, so the copy may not start immediately. A "(Copy: Pending)" badge appears beside the new database’s name.
During the copy process, the new database appears in the list of databases, but is inaccessible. When the copy completes successfully, the new database becomes accessible. If the copy fails, the new database is removed from the list of databases and does not become accessible.
Limitations
-
Snapshots for databases nested 10 levels (or more) below a top-level parent database cannot be made. However, if you backup a database that includes child databases (no matter how deeply nested), the child database is backed up along with the parent database.
-
Up to 5 restores can be in process at once. If you attempt to restore more than 5 databases at once, an error message appears.
-
Snapshots are created once per day, at or near 6am UTC, and are internally consistent up to the logical time that the snapshot was taken. Snapshots do not contain any subsequent schema/document changes or index builds completed after the transaction time of the snapshot.
Any index builds which have started, but not completed, before a database snapshot was taken does not resume when the snapshot is restored. Once restored or copied, such indexes would have a status of
active: false. If you wish to resume the build of these indexes you would need to delete the index and then recreate it.We recommend that you investigate the restored database for inactive index builds every time you restore or copy from a snapshot!
Is this article helpful?
Tell Fauna how the article can be improved:
Visit Fauna's forums
or email docs@fauna.com
Thank you for your feedback!