Using the backup feature in Binero.Cloud, you are able to backup and restore volumes. Backups will be stored on the object storage of your account in availability zone europe-se-1b using the gp.archive flavor.
When backing up volumes from availability zone europe-se-1b, note that the backups currently will also end up in the same availability zone (and, in part, on the same storage). If you have data that is not also stored in zone europe-se-1a, we recommend using a different backup in order to secure your data for a potential storage outage in zone europe-se-1b.
The backup service in Binero.Cloud backs up volumes. When backing up a volume, data will be copied bit-by-bit from the source to the destination over some time (it takes time to copy large amounts of data). If data is also being written to the source disk during copying, the data on the destination server may get corrupted. A way to work around this is to shut down the server but since this may not always be an option, taking some time to consider the potential impact of corrupted data might be advisable.
For a fileserver, the risk of corrupted files should be minimal (and in the event a file is compromised, the damage is limited to that file). When backing up a database, however, the entire database might be reliant on a few files and should one of them be compromised, the database will not start again. In this scenario, the usual solution is to first run a dump of the database data onto a file on the filesystem. This file would then be safe (as its not written to after the dump) and in the event of a restore, the file could just be read back into the database.
A way to work around this problem (in part) is to first snapshot your volume and then backup the snapshot. That way, new writes will be moved away from the snapshot (which is read-only) and data will be safer. Bare in mind that a snapshot could also cut writes in half so exporting databases is still advisable.
Shutting of your instance will of course make the backup entirely safe from above issues.
We strongly recommend doing a restore-test of your backups. Since restoring to a new volume and creating a new instance that could run parallel to the real one is very easy, this is a good way to ensure data consistency in your backup.
Setting up backup¶
There are two main ways to backup data using Binero.Clouds backup feature:
When doing a manual backup, your data would be pushed to the backup storage once upon request. This could be done for instance, before doing a migration or upgrade (although a snapshot might also be a good alternative for this) or if you want to have a copy of an installed server stored offline in the event of the real server for instance being deleted - and then backing up the data separately. More information in our Setting up manual backup article.
The platform is able to automatically run backup jobs for you. This can be setup via the platform automation tool, however we strongly recommend using our service catalog to simplify creating an automated backup job. The platform will not do incremental backups when using the built in workflow to run backups. More information in our Setting up automatic backup article.
Before running a backup-job, please note that you are strongly recommended to also dump any database to disk before running the job. If the job is ran on a schedule, also dump your database on a schedule inside your instance (and do it before the backup job is ran).