0 4 * * * to back up at 4 AM every night. On the other hand, you can also just mount multiple volumes under /backup to have all of them backed debian-flavored cron expression for when the backup should run. This can be a space-separated list if you need to back up multiple paths, when mounting multiple volumes for example. If you need a more complex script for pre/post exec, consider mounting and invoking a shell script instead. Similarly, after the temp volume has been backed up, it's cleaned up with another docker exec in the database container, this time just invoking rm. Note that the main InfluxDB data volume ( influxdb-data) isn't used at all, as it'd be unsafe to read while the DB process is running. The resulting DB snapshot is written to a temp volume ( influxdb-temp), which is then backed up. The above configuration will perform a docker exec for the database container with influxd backup, right before the backup runs.
Backup exec 2010 service keeps stopping archive#
backups:/archive # Mount a local folder as the backup archive volumes: influxdb-temp:/backup/influxdb:ro # Mount the temp space so it gets backed up var/run/docker.sock:/var/run/docker.sock:ro # Allow use of the "pre/post exec" feature Image: jareware/docker-volume-backup volumes: docker-volume-backup.exec-post-backup=rm -rfv /tmp/influxdb backup: docker-volume-backup.exec-pre-backup=influxd backup -portable /tmp/influxdb # These commands will be exec'd (in the same container) before/after the backup starts: influxdb-temp:/tmp/influxdb # This is our temp space for the backup labels: influxdb-data:/var/lib/influxdb # This is where InfluxDB keeps its data If you don't want to stop the container while it's being backed up, and the container comes with a backup utility (this is true for most databases), you can label the container with commands to run before/after backing it up: This configuration allows you to safely back up things like databases, if you can tolerate a bit of downtime. grafana-data:/backup/grafana-data:ro # Mount the Grafana data volume (as read-only) volumes: var/run/docker.sock:/var/run/docker.sock:ro # Allow use of the "stop-during-backup" feature sudo mv /var/lib/docker/volumes/bla-bla/_data volumes: Move any existing data aside, with e.g.Stop Grafana, with docker-compose stop dashboard.This is where your live Grafana keeps its data on the host file system. Let's say it ends up being /var/lib/docker/volumes/bla-bla/_data. docker volume ls and then docker volume inspect. Figure out the mount point of the grafana-data volume, with e.g.This would leave you with a new directory called backup in the current dir. Extract the contents of the backup, with e.g.$ docker-compose exec -T backup bash -c 'aws s3 cp s3://$AWS_S3_BUCKET_NAME/$BACKUP_FILENAME -' > įrom here on out the restore process will depend on a variety of things, like whether you've encrypted the backups, how your volumes are configured, and what application it is exactly that you're restoring.īut for the sake of example, to finish the restore for the above Grafana setup, you would:
0 kommentar(er)
