Database Group Topology
This shows all active server-wide and database-specific periodic backups.
Creating Periodic Backups
Defining Periodic Backups
Task Name (Optional)
Choose a name of your choice
If no name is given then the RavenDB server will create one for you based on the defined destination
Backup Task Type:
Backed Up Data: The database data in a JSON format, including documents, indexes (definitions only) & identities
(same as exported database format)
Size of backup data: Smaller
Backup Speed: Faster
Restoring: Slower, Indexes have to be rebuilt from their definitions
Backed Up Data: The raw database data including the indexes (definitions and data)
Size of backup data: Larger
Backup Speed: Slower
Restoring: Faster, Indexes do not have to be rebuilt
Preferred Node (Optional)
Select a preferred mentor node from the Database Group to be the responsible node for this Backup Task
If no node is selected, then the cluster will assign a responsible node (see Members Duties)
Select the content to back up. Note: Both incremental and full backups can be scheduled at the same time.
Scheduling Two Backups
Full Backup will back up all the database data every time the task is scheduled to work.
A Snapshot can only occur when scheduling 'Full'.
Incremental Backup will only back up the delta (changes made) of the data since the last backup that has occurred.
If onlyIncremental Backup is set, then a Full Backup will occur only the first time that the task is triggered,
followed by Incremental Backups according to the scheduled time.
The Full Backup that is done the first time will be either a 'Backup' or a 'Snapshot', depending on the type selected.
Data that is backed up in Incremental Backup is always of type 'Backup' - even if the Backup Task Type is 'Snapshot'.
'Backup' types save index definitions, but not the fully built indexes.
Schedule the Backup Tasks to occur at regular intervals (daily, monthly, hourly, every minute) at specific times.
Save on data transfer with frequent "incremental" backups and recover lost data with infrequent "full" backups
To save on data transfer costs you can schedule frequent 'incremental' backups, (which save any changes made since the previous backup).
To ensure that you can recover lost data, schedule infrequent 'full' backups.
Infrequent backups can be useful if a mistake was made and you need access to data from a few days ago.
If downtime while recovering databases is a concern, you can also set up an external replica and manually fail over to it while you recover the data onto the original cluster.
To save storage space, you can set obsolete scheduled backup files to delete automatically after the time period that you define.
Old backups are deleted after the defined time period during the next scheduled backup.
Backup Retention Policy
Enable / disable the retention policy. If disabled, the backups are stored indefinitely, which may use a lot of storage. We recommend enabling it so that the deletion of obsolete backups can be scheduled.
Select the retention period.
Some organizations require backups to be stored for as long as 7 years. If this is the case, consider the issue when scheduling and setting the retention policy.
Backups can be encrypted. Make sure that you save the encryption key well.
More than one destination can be selected at the same time. The backup process will first write the backup to the local path (or to a temporary path if the local path is not specified).
Once that's done, the backup owner will start uploading the backup to all remote destinations in parallel.
If any of the remote destinations fail, the entire backup will be considered to have failed.
For a resilient data protection strategy
that protects your databases from natural disasters and theft, we recommend scheduling concurrent backups on a local machine and on the cloud.
This strategy is known as the 3-2-1 Backup Rule.
Periodic Backup Details
Periodic Backup Details
Backup Task Details:
Active / Not Active / Not on Node
List of all backup destinations defined
Last Full Backup
The last time a Full Backup was done
(Snapshot / Backup type - depending on task definition)
Last Incremental Backup
The last time an Incremental Backup was done
Next Estimated Backup
Time for next backup
(Full Backup / Incremental Backup / Snapshot - depending on task definition)
Backups older than this period will be deleted during the next backup.
In addition to the scheduled time defined, you can backup your data now.
This is useful before software updates or any other action where data may be lost.
The scheduled backup will still be triggered as defined.
Click to refresh this panel viewed details
Manually Creating One-Time Backups
Manual Backup Tasks View
Manual Backups View
Create a one-time manual backup.
This can be vital before upgrading or whenever you want an unscheduled backup.
When the delay period has passed, the backup operation is executed
from scratch, using no material from the initial delayed run,
and its future schedules are enabled.
Delaying a running backup operation may be useful when, for example,
backup creation time turns out to be much longer than anticipated,
system resources are currently limited (e.g. on the cloud), or another
process currently overuses resources.
To delay a running backup task:
Open the notifications center, find the notification regarding the
execution of the backup task you want to delay, and click the notification's
Periodic Backup Notification
When the Backup Details popup appears, click the Delay backup button.
Backup Details Popup
Select a delay period and confirm.
Backup tasks can be delayed using this Studio option for a preset time period,
e.g. an hour or a day.
You can also delay tasks for a custom time period via code, applying the
When the Cluster or Node is Down
When the cluster is down (and there is no leader):
Creating a new Ongoing Task is a Cluster-Wide operation,
thus, a new Ongoing Backup Task cannot be scheduled.
If a Backup Task was already defined and active when the cluster went down,
then the Backup Task will still continue to execute on its defined schedule (on its responsible node).
But, it will fail to be reported to the cluster and may be run again after the cluster has recovered.
When the responsible node is down
If the responsible node for the Backup Task is down during the scheduled time,
then another node from the Database Group will take ownership of the task so that there are no gaps in your backups.
Backup Task -vs- Replication Task
RavenDB's External Replication provides you with an off-site live replica/copy of the data
('live' meaning that any changes in the database will be duplicated into the replica immediately).
If one database is down, replicas (other nodes in the cluster) can continue its work, thus greatly improving availability.
Replication is also quite useful if you need to:
Shift operations to a secondary data center
Share the workload across more than one server.
But a replica isn't a backup. It doesn't present good solutions for many backup scenarios. For example, backups can:
Protect you from an accidental collection delete
Tell you the state of the system at, say, 9:03 AM last Friday
Protect you from various cyber attacks
A backup keeps an exact state of the database at a specific point in time and can be restored.