3.6 KiB
Database Backup
Periodically do a backup of a database
This app uses Ofelia to schedule a backup routine which may store one or more databases according to configuration.
Configuration
Setup is made populating the BACKUP_DATABASES environment variable with a list of backup configuration. Each backup setup must be in a single line and have two items: a database URL and a cron-like string indicating the periodicity of the backup.
Examples
All examples listed refer to the (hipotetical) mysql server mydatabase.com.br logged with the username db_user:
- schema: mysql (at this moment is the only database supported)
- username: db_user
- host: mydatabase.com.br
mysql://db_user:123456@mydatabase.com.br:3306/database-to-backup @hourly
- password: 123456 (login will be attempted with this password)
- port: 3306 (as it is the default port for mysql it could be ommited)
- database: database-to-backup (only this database are going to be backuped and ommiting this value will vary depending on the database, generaly meaning backuping all accessible databases)
- schedule: @hourly (each 60 minutes, with the first occurence 60 minutes after starting the system) mysql://db_user:123456@mydatabase.com.br 0 0 1 * * *
- password: 123456 (login will be attempted with this password)
- schedule: 0 0 1 * * * (in (GO implementation cron format)[https://godoc.org/github.com/robfig/cron])meaning on this case every night at 01h00) mysql://db_user@mydatabase.com.br/* @daily
- schedule: @daily (onde a day starting 24h from starting)
Remote volumes
A presistência dos dados backupeados depende obviamente da criação de um volume persistente no Docker. O ideal é que esse volume esteja fora do servidor. Um serviço compatível com s3 pode ser um bom local de armazenamento e para essa possibilidade incluimos scripts de configuração para os serviços s3 mais comuns (nesse caso, mas comuns pra nós).
Para que o volume esteja disponível em todos os nós do cluster nós precisamos fazer a configuração previamente em cada servidor, instalando no docker um plugin que vai armazenar as informações de acesso ao serviço s3. O exemplo abaixo ilustra a instalação do plugin para acesso a uma conta no Cloudflare R2.
setup-cloudflare-r2.sh --account-id="<ID da conta>"\
--key="<Chave de Acesso>"\
--secret="<Chave secreta>"\
--alias="backup-bucket";
A configuração de um bucket no Linode Objects também está coberta por um script próprio. No futuro esses scripts serão unificados num mesmo processo por isso evite fazer qualquer automatização confiando na existência deles. O conteúdo dos scritps é simples e pode ser facilmente adaptado para outros serviços.
A montagem do bucket é feita pela API "Service Update" do Docker, por meio da interface que o Caprover oferece. O JSON abaixo montará um bucket chamado "backup" criado no serviço s3 configurado pelo plugin com nome ou alias "backup-bucket" no caminho /var/data/backup-databases.
{
"TaskTemplate": {
"ContainerSpec": {
"Mounts": [
{
"Type": "volume",
"Source": "backup",
"Target": "/var/data/backup-databases",
"VolumeOptions": {
"DriverConfig": {
"Name": "backup-bucket"
}
}
}
]
}
}
}
O formato YML também deveria ser válido mas nas versões atuais do Caprover a configuração abaixo foi ignorada
TaskTemplate:
ContainerSpec:
Mounts:
- Type: volume
Source: backup
Target: /var/data/backup-databases
VolumeOptions:
DriverConfig:
Name: backup-bucket