Skip to main content

Backup & Restore: FAQ

Frequently Asked Questions​

Is there a one-time backup?​

Yes, you can create a backup for any database immediately.
It is recommended to run periodic backup tasks that continuously create backups at predefined time intervals, but it is also possible to create one-time backups whenever needed.

There are two ways to create a backup immediately:

  • Configuring and running a one-time backup operation.
  • Triggering any existing database backup task to create a backup immediately, outside its schedule.

Learn to create a one-time backup via the client API or Studio

Can I back up my entire cluster rather than just one database?​

Yes, instead of creating a backup task for each database individually, you can define a single periodic server-wide backup task.

  • The server will apply your backup configuration to all databases by creating per-database backup tasks.
    Even databases added after the server-wide task was defined will be included in the backup when they are created.

  • Backups will be kept for each database separately, containing the same content as regular database backups.

  • After backing up all databases, you can rebuild the cluster configuration and nodes setup and restore the databases one by one.

  • You can prevent downtime while rebuilding the cluster by replicating any database.
    This will keep a live version of the database and maintain the replica as a failover.

Learn to create a periodic server-wide backup task

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

Although external replication and backup tasks are both ongoing routines that safeguard your data, their aims and methods are very different.

  • An external replication task provides you with a live off-site copy of a database, instantly replicating any changes to the database content.
    Having a replica ready to immediately take over can help when:

    • A database is down.
    • You are shifting operations to a secondary data center.
    • You need to share the workload with an additional server.

  • But a replica cannot replace a backup in numerous scenarios, including:

    • An accidental collection delete or a patch operation gone wrong.
    • A cyber attack that compromises the database.
    • A need to restore the database to a specific point in time.

So while an external replication task can be a great addition to your data safety strategy, it is not a 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' timestamps will remain consistent even when the backups are created by different nodes.

Can I simply copy the database folder when I need a backup?​

Copying a live database folder lacks the guaranteed ACID compliance of a proper backup operation, and might cause data corruption during restore.
It also lacks many advantages of periodic backup tasks, including:

  • A continuous backup routine providing up-to-date backups.
  • Reliable point-in-time restore points for post-failure recovery.
  • Backup encryption for secure storage.
  • Incremental backups, saving only the changes since the last backup.
  • Retention policies, automatically deleting old backups to free up storage space.

Does RavenDB automatically delete old backups?​

By default, RavenDB does not automatically delete old backups. Backups are stored indefinitely, and will only be deleted when you remove them.

You can, however, set a retention policy that defines an expiration age for backups. Backups whose age exceeds this limit will be automatically deleted.

Are there any locations where backup files should NOT be stored?​

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.
For example, disk space may run low as backups accumulate or the database grows.

One-time backup operations and periodic backup tasks can keep backups in a variety of destinations, including a local path, an FTP target, and cloud destinations like Azure storage or Google Cloud.
For example, you can set a backup task to keep backups locally as well as send them to an Amazon S3 bucket.

What happens when a backup process fails or is aborted before completion?​

  • While in progress, the backup content is written to an .in-progress file on disk.
    Once the backup operation is complete, the file is renamed to its correct final name.
  • If the backup process fails or is aborted, the .in-progress file will remain on disk.
    This file will not be used by any future restore operation.
    If the failed process was an incremental backup task, the next incremental backup will pick up from the last successfully completed backup, ensuring consistency.

What happens if the node responsible for a backup task is down?​

When the responsible node is down during the scheduled time, another node from the database group will assume ownership of the task, so there will be no gaps in the backup schedule.

What happens when the cluster is down?​

When the cluster is down (and there is no leader):

  • Creating a new task is a cluster-wide operation.
    Therefore, a new backup task cannot be scheduled.

  • If a backup task was already defined and is active when the cluster goes down,
    the task will continue to execute on its defined schedule on its responsible node.
    However, it will fail to be reported to the cluster, and the missed backup may be re-executed when the cluster recovers.

In this article