Backup Task
-
Backups save your data at a specific point in time, and allow you to restore your database from that point. Learn more in Backup Overview.
-
A backup is not equivalent to replicating your data, as explained below in Backup -vs- Replication
-
Configure the following when creating a Backup Task:
- Backup Type - Select Backup/Snapshot
- Backup Time - Schedule the task time
- Backup Content - Select Full/Incremental
- Backup Retention Policy - Schedule deletion of backups
- Backup Destination - Select the backup destination
-
In this page:
Backup Task - Definition
Create New Backup Task
-
Task Name (Optional)
- Choose a name of your choice
- If no name is given then RavenDB server will create one for you based on the defined destination
-
Backup Task Type:
-
Backup
- 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 database data in a JSON format, including documents, indexes (definitions only) & identities
-
Snapshot
- 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
-
Backup
-
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)
Backup Task - Content & Scheduling
Backup Task Schedule & Content
-
Select the content to back up. Note: Both types can be scheduled.
-
Full Backup
Full Backup will back up all the database data every time the task is scheduled to work. -
Incremental Backup
Incremental Backup will only back up the delta (changes made) of the data since the last backup that has occurred.
-
-
Schedule the Backup Task time using a Cron Expression.
(eg. "0 0 12 * * ?" means "0 seconds, 0 minutes, 12pm (noon), every day, every month") -
Notes:
-
If only Incremental Backup is set, then a Full Backup will occur only in 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'.
A Snapshot can only occur when scheduling 'Full'.
-
Scheduling two backups
To save on transfer costs you can schedule frequent incremental backups
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.
-
In the image "Backup Task Schedule & Content" above:
- A Full Backup is scheduled every day at 02:00 AM - and in addition to that -
- An Incremental Backup is scheduled every 6 hours
Backup Task - Retention Policy
Retention Policy
-
Enable / disable the retention policy. If disabled, the backups are stored indefinitely. If enabled, deletion can be scheduled.
-
Select the retention period. Once a backup is older than the specified amount of time, it will be deleted during the next scheduled backup task.
Backup Task - Destination
Backup Destinations
-
Select backup destinations and enter your credentials for each
-
Available destinations:
- Local - Set a folder of your choice (any directory that can be accessed from your machine)
- Amazon S3
- Microsoft Azure
- Google Cloud
- Amazon Glacier
- FTP - Set your FTP protocol & server address
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.
Backup Task - Details in Tasks List View
Tasks List View Details
-
Backup Task Details:
- Task Status - Active / Not Active / Not on Node
- Destinations - Local or cloud-based
- Last Full Backup - (Snapshot / Backup type)
- Last Incremental Backup
- Next Estimated Backup - Time until next scheduled backup and which type it will be (Full Backup / Incremental Backup / Snapshot - depending on task definition)
-
Graph view:
View of the Backup Task responsible nodes -
Backup Now:
In addition to the scheduled time defined, you can backup your data now.
The scheduled backup will still be triggered as defined. -
Refresh:
Click to refresh this panel viewed details
Backup Task - When 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.
- If the responsible node for the Backup Task is down during the scheduled time,
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 reflected in the replica once they occur).
If one database is down, the replica can continue its work, thus greatly improving availability.
This 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.
- A new database can be created from a Backup
- This can be done with both 'Backup' & 'Snapshot' types