Community container for zero-downtime backups

[gggeek]

I have not measured how long the daily backup procedure takes on a big installation, but I think that we could strive to give users, at least an option, the possibility of producing backups without stopping the containers at all.

This could be driven by a community-container or an official one, and should of course come with a big disclaimer that there could be inconsistencies between the different types of data backed-up (and for file-based sets, even within the single set).

In my own experience, working for customers with eg. big CMS installations, many of them would accept the risk of a backup where the file storage is not 100% in sync with the db and the search index - as long the db is consistent with itself (iow. the db is considered the primary source of truth). In large part because zero downtime was very important to them, and the technology to take instant, exact-same-time snapshots of both a db and a large file store was either too costly or not available at all for their chosen platform.

The process could follow these steps:

backup:

• back up the db using the pgsql native pgdump tool
• back up the file storage via file copy
• back up the containers/AIO configuration via file copy
• back up the search index using the native replication (dump?) capability of Elastic
• redis: any data to back up at all?
• community containers: to be seen, but I presume most boil down to a db+file store

restoration:

• stop services
• bring back the files
• reload the db
• start the services
• run a search reindexation in the background

WDYT?

[szaimen]

Hi, sounds good to add a community container for this. PRs are welcome!