You are currently browsing legacy 4.0 version of documentation. Click here to switch to the newest 5.1 version.

We can help you with migration to the latest RavenDB

Contact Us Now
see on GitHub

Backup & Restore: Frequently Asked Questions


  • Q: Is there a one-time backup?
  • A: No. Backup is an on-going task, and is meant to back your data up continuously.
    • If you wish, you can trigger it for immediate execution and then disable the task.
    • You can also use Smuggler as an equivalent of a full backup for a single export operation.

  • Q: How do I create a backup of the whole cluster?
  • A: Backup and restore your database group's data.
    The cluster and its information regarding the database and nodes can be easily re-created, there's no need for a backup for this.

  • Q: How should I set nodes' time?
  • A: The Backup task always uses the 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.

  • Q: Can't I simply copy the databases directory whenever I need to create a backup?
  • A: Simply copying the databases folder is not a good substitute for RavenDB's backup procedures.
    Creating a backup routine is a one-time operation. There really is no reason to do it manually again and again.
    RavenDB's own backup also has a few advantages. Among them:
    • RavenDB creates a reliable point-in-time freeze of backed-up data.
    • RavenDB ensures backed ACIDity, preventing any dependencies upon files or connections during restoration.

  • Q: Does RavenDB automatically delete old backups?
  • A: No, RavenDB does not automatically remove backup files, you need to take care of it yourself.
    You can use services like crontab (a linux scheduling procedure) to create an old-backup-files-removal routine.

  • Q: Are there any locations in which I better not store backup files?
  • A: It is recommended not to store your backups on the same drive as your database's data files, to avoid self inflicted scenario of a database storage distress because of backups piling on.