You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
One of the best ways of backing up a Docker server is to use a filesystem that supports snapshots (eg. zfs), and just backup those snapshots. Or simply choose a hosting provider that does this for you (usually for an extra monthly fee; but Proxmox also has good support for this if you want to stick to self-hosting.) This approach is easy because it centralizes everything into one backup task. There's only one thing to worry about backing up: everything.
It might be nice though to have separate backups for each volume, selecting only those volumes you really care about, and having different configurations for each of these. Instead of backing up the files in the native filesystem, you connect a backup container to each volume you have configured, and backup the files through the volume mount. This has the advantage that it does not require control of, nor coordination with, the host filesystem. It can all be done through connecting regular docker containers to volumes and performing the backup directly from the container.
I imagine this could be done with a new top level service that runs restic and you would configure all of the volumes that you want it to mount and to backup to S3. These volumes would be the data volumes of all the other containers you wish to backup. The sftp container is an example of a service that connects to several volumes through SFTP_VOLUMES, so RESTIC_VOLUMES could be a similar thing.
There is concern of backing up files that are not flushed to disk, ideally the services would be shutdown before the backup, and turned back on afterward. Other mitigations include blocking the network access during backups (but not shutting down the service), or sending a signal to the service to tell it to flush. For the purpose of this service, I'm not too concerned about it. You should not rely on this for databases. That is why the postgres service implements pgbackrest, because it is a backup strategy that is specially made for that database. So use that for postgres, not this. For a lot of files though, they never (or hardly ever) change, or do so in a predictable way. For these I think it doesn't matter that these services are shutdown or not, and just let restic backup what has been flushed regardless.
The text was updated successfully, but these errors were encountered:
One of the best ways of backing up a Docker server is to use a filesystem that supports snapshots (eg. zfs), and just backup those snapshots. Or simply choose a hosting provider that does this for you (usually for an extra monthly fee; but Proxmox also has good support for this if you want to stick to self-hosting.) This approach is easy because it centralizes everything into one backup task. There's only one thing to worry about backing up: everything.
It might be nice though to have separate backups for each volume, selecting only those volumes you really care about, and having different configurations for each of these. Instead of backing up the files in the native filesystem, you connect a backup container to each volume you have configured, and backup the files through the volume mount. This has the advantage that it does not require control of, nor coordination with, the host filesystem. It can all be done through connecting regular docker containers to volumes and performing the backup directly from the container.
I imagine this could be done with a new top level service that runs restic and you would configure all of the volumes that you want it to mount and to backup to S3. These volumes would be the data volumes of all the other containers you wish to backup. The sftp container is an example of a service that connects to several volumes through SFTP_VOLUMES, so RESTIC_VOLUMES could be a similar thing.
There is concern of backing up files that are not flushed to disk, ideally the services would be shutdown before the backup, and turned back on afterward. Other mitigations include blocking the network access during backups (but not shutting down the service), or sending a signal to the service to tell it to flush. For the purpose of this service, I'm not too concerned about it. You should not rely on this for databases. That is why the postgres service implements pgbackrest, because it is a backup strategy that is specially made for that database. So use that for postgres, not this. For a lot of files though, they never (or hardly ever) change, or do so in a predictable way. For these I think it doesn't matter that these services are shutdown or not, and just let restic backup what has been flushed regardless.
The text was updated successfully, but these errors were encountered: