Quiet GitLab for consistent backup

Problem

It is difficult to produce frequent, internally consistent backups of a large GitLab instance for many reasons.

For example, it is composed of multiple unique datastores. It requires total downtime. And each datastore can have too much data to be able to use any kind of transfer mechanism during a reasonable, regular maintenance window.

Proposal

From &7333 (comment 1270817153):

the idea of an API contract to quiet an instance (which can currently be achieved with a full shutdown) so that scaled third party backup can be reliably recommended.

In the case of AWS, the AWS Backup service is a managed (including incrementals and cross region backup replication),multi-service checkpointing service. So a quiet instance can be reliably snapshot backed up across many data storages and done so with incrementals - dramatically lowering the length of the required "quiet period".

While not all cloud backups have this level of abstracted Backup Service - we can make a recommendation for the many deployed on AWS. A technology specific MVC.

However, the "quiet while backing up" API contract would enable all scaled multi-storage capable third party backup solutions on the market to be candidates for GitLab backup.

@DarwinJS Could you expand on this as a feature request?

At the moment, only critical fixes can be scheduled in Category:Backup/Restore of GitLab instances. But perhaps it could be useful to define a quick win.

At the moment, we attempt to quiet a GitLab instance prior to a planned Geo failover at the step Prevent updates to the primary site.

We also have similar instructions in this Migrate to a new server section of Backup and restore.

I am not clear on the idea. Is it to use an API endpoint to trigger GitLab to move to a quiet state?