Backup & Restore:
Frequently Asked Questions

Is there a one-time backup?

Yes. Although backup is a vital ongoing task and is meant to back your data up continuously, you can also use Backup Now (e.g. before upgrading or other maintenance).

• You can also use Smuggler as an equivalent of a full backup for a single export operation.

How do I create a backup of my cluster configuration?

Only database contents and indexes can be backed up. Cluster configuration and nodes setup can be re-created and restored from backup, so no special backup procedure is needed for it.

You can replicate your database so that there is a live version available to distribute the workload and act as a failover in case of cluster failure while you restore the database.
Is an External Replication a good substitute for a backup task?

How should the servers' time be set in a multi-node cluster?

The backup task runs on schedule according to the executing server's local time.
It is recommended that you set all nodes to the same time. This way, backup files' time-signatures are consistent even when the backups are created by different nodes.

Is an External Replication task a good substitute for a backup task?

Although External Replication and Backup are both ongoing-tasks that create a copy of your data, they have different aims and behavior. For example, replication tasks don't allow you to retrieve data from a history/restore point after mistakes, but they do create a live copy that can be used as a failover and they can distribute the workload.
See Backup Task -vs- External Replication Task.

Can I simply copy the database folder contents whenever I need to create a backup?

Simply copying the database folder of a live database will probably create corrupted data in the backup.
Creating an ongoing backup task is a one-time operation. There really is no reason to do it manually again and again. Properly backing up provides:

• Up-to-date backups by incrementally and frequently updating changes in the data.
• The creation of a reliable point-in-time freeze of backed-up data that can be used in case of mistaken deletes or patches.
• The assurance of ACID compliance for backed up data during interactions with the file system.

Does RavenDB automatically delete old backups?

You can configure RavenDB to delete old backups with the RetentionPolicy feature.
If you enable it, RavenDB will delete backups after the TimeSpan that you set.
By default, RetentionPolicy is disabled.

Learn how to change the Retention Policy via API.
Learn how to change the Retention Policy via RavenDB Studio.

Are there any locations that backup files should NOT be stored at?

It is recommended not to store backups on the same drive as your database data files, since both the database and the backups would be exposed to the same risks.

• Disk space can run low as backups start piling up unless you set your retention policy for backups.
• There are many options for backup locations.
• We recommend creating ongoing backups in two different types of locations (cloud and local machine).
  You can store your backups in multiple locations by setting up one on-going backup task with multiple destinations.

What happens when a backup process fails before completion?

While in progress, the backup content is written to an *.in-progress file on disk.

• Once backup is complete, the file is renamed to its correct final name.
• If the backup process fails before completion, the *.in-progress file remains on disk.
  This file will not be used in any future Restore processes.
  If the failed process was an incremental-backup task, any future incremental backups will continue from the correct place before the file was created so that the backup is consistent with the source.