It is important to take regular backups of your clusters. Besides providing a safety net in case of data corruption, backups can also used for various operations, such as creating copies of your data for testing, moving data from one Kurrent Cloud Project to another, or changing from one type of access from Public to Private, or vice versa.
There are two types of backups:
- Manual Backups: These are backups that you create on demand using the Cloud Console and the Kurrent Cloud CLI.
- Scheduled Backups: These are backups that are created automatically by a that defines the frequency and number of backups to keep at a time.
Both types of backups can be viewed in the Backups view of the console. All backups created by the same job will be grouped together in one row, which can be expanded by clicking the down arrow icon on the right side of the row.
Manual Backup
Backups can be created on demand using the Cloud Console and the Kurrent Cloud CLI.
You can customise the backup label using a combination of free-text and predefined variables:
- index—: the auto-incremented value with the number of backups. You can format it as:
- decimal:
index:decimal(default), - hexadecimal:
index:hex.
- decimal:
- cluster: value from the cluster information:
- description:
cluster:description(default), - id:
cluster:id, - cloud provider:
cluster:provider
- description:
- datetime: timestamp of when backup was made. You can format it as:
Scheduled Backups
Scheduled backups can be created through the Cloud Console and the Kurrent Cloud CLI
Scheduled backup jobs can be run as frequently as once an hour. After each successful backup, older backups created by the same job will be automatically deleted based on the provided configuration.
Note
Limitation: Only one backup can be created for a cluster at a time.
When a backup begins, a resource lock is placed on that cluster from other operations, such as modifying, deleting, and creating additional backups for the duration of that backup creation operation.
Multiple scheduled backups can target the same cluster. However, if schedules overlap or a manual backup is in progress, any jobs that are attempting to start after the first backup job has started will fail as the first backup job to start will have locked the cluster.
For example, you could create one scheduled backup that executes every hour, along with a second scheduled backup that executes once a week. Backups from these scheduled jobs are pruned independently regardless of their age, so if both saved a maximum of four backups, the oldest backup from the weekly job might be close to a month old, while the hourly job's backups would never be older than a fraction of a day.
Tips
To avoid this issue, you can offset scheduled backup jobs that might overlap by 15 to 30 minutes. Some providers can take longer to create backups, particularly for larger disks. You may need to adjust the offset if you encounter backup failures for this reason.
Backup Failures
While backups failures are not common, there are several scenarios that can cause the creation of a backup to fail. The most likely causes are:
- The cluster is locked by another operation, such as another backup is in progress, disk expansion, cluster resize, database upgrade, etc.
- The cluster is not in a healthy state, such as if there is a node that is not responding or behind on replication.
- The cloud provider is taking longer than expected to create a volume snapshot.
If a backup fails, the cluster will be unlocked and the backup will be marked as Defunct in the console. If the backup was created by a schedule job, the defunct backup will be it deleted when it is scheduled to be pruned. One-off backups must be deleted manually.
Warning
If a backup becomes defunct due to a timeout waiting for the cloud provider, the snapshot may still have been created, and you will be charged for the snapshot storage.
Tips
You can receive notifications of backup failures by setting up an to have an alert generated, notification sent to a chat channel or via email.
Restore from backup
Restores can be done on demand using the Cloud Console and the Kurrent Cloud CLI.
The topology of the new cluster does not need to be the same as the source of the backup: you can restore a 3 nodes cluster backup to a single node one. Additionally, you can restore a backup to a different network in the same cloud provider and region in the same project or another
Note
Limitations:
- Restoring a backup will create a new cluster
- You cannot restore a backup in place, a restored cluster will have a different ID than the source cluster
- You cannot restore a backup to a different cloud provider or different region within the same cloud provider
- You can only restore a backup to a disk size that is the same size or greater than the source cluster