Point-In-Time-Recovery
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Release notes
Problem to solve
Typically, a full or incremental backups are taken once or twice a day at most due to resources needed to take and store these backups. The data generated between the time a disaster occurs and the time the last backup was taken is lost and it is defined as a measure of time - Recovery Point Objective (RPO). For very active GitLab instances the data loss can be significant.
Further, rolling back to the last successful backup when the exact time of corruption is known may result in more data loss than is necessary. For example, if the last known backup was 24 hours ago and the corruption event occurred 3 hours ago, restoring from the backup will result in 21 hours more loss of data than is necessary to recover from the corruption.
This results in loss of productivity and loss of revenue for our customers.
Intended users
User experience goal
The point-in-time recovery will be at an instance level. All interaction will be via the CLI to start with.
Restoration requires the backup tool to know the location and have access to
- Previous backups
- Database transaction logs
- Gitaly transaction logs
This information must be available to the backup tool as a configuration.
Proposal
PostgreSQL supports transaction logs and Gitaly will support transaction logs in the future.
In the event it is necessary to recover from a corruption incident, it should be possible to restore the last known successful backup and replay the transaction logs for both the database and Gitaly to bring the GitLab instance to a state just before the corrupt event occurred.
The GitLab instance's PostgreSQL database would need to be setup to generate transaction logs and stream them to a remote storage location. Managed database services such as RDS and CloudSQL support PostgreSQL transaction log streaming natively within the offered service. The MVC will target managed databases only. We will extend support for Linux-packaged PostgreSQL in the future.
Gitaly transaction logging would need to be configured and streamed to a remote location.
The restoration point is defined as a date and time option. The backup tool will need access the last successful backup and the respective transaction logs for the Database and Gitaly. This information can be provided to the tool as a configuration.
The unified backup will restore GitLab instance using the last known backup and replay the transaction logs up to the restoration point passed as an option.
The backup will need to be restored onto a GitLab instance that's running the exact same version of GitLab on which the backup was taken.
Below is an illustration of how the transactions logs work in conjunction with the backups:
Further details
Permissions and Security
Permissions will be inherited from Unified backup tool.
Permission to access the locations where the backups and transaction logs are stored will be necessary. The authentication permissions should be stored as configuration.
Availability & Testing
Available Tier
- Free
- Premium/Silver
- Ultimate/Gold
Feature Usage Metrics
TBD
What does success look like, and how can we measure that?
What is the type of buyer?
Is this a cross-stage feature?
No
What is the competitive advantage or differentiation for this feature?
Links / references
This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.