Backups of GitLab.com
This is a Controlled Document
In line with GitLab’s regulatory obligations, changes to controlled documents must be approved or merged by a code owner. All contributions are welcome and encouraged.Purpose
This policy outlines how GitLab performs, monitors, and validates backups and restorations of GitLab.com. These procedures are critical for ensuring data recovery and disaster recovery for customer data.
Scope
GitLab.com’s backup strategy includes both monitoring and restore validation.
Customer data is stored in the following locations:
- All PostgreSQL databases for GitLab.com
- Object storage for GitLab.com, including packages, LFS, uploads, and CI data
- The CustomersDot database, which manages subscriptions and purchases
- Git repositories
Not in Scope
- Customer Data stored in the Redis cache
- Data queued for processing
- Sessions and other cached data
Roles & Responsibilities
| Role | Responsibility |
|---|---|
| GitLab Team Members | Ensure adherence to the requirements outlined in this policy |
| Engineering (Code Owners) | Approve significant changes and exceptions to this policy |
Procedure
GitLab defines:
- The services requiring backups
- The frequency of backups, data retention periods, and restoration processes
- The procedures for data restoration for Disaster Recovery scenarios
Backup and Restore
PostgreSQL Databases
| Area | Details |
|---|---|
| Backup frequency | A full backup is taken every 24 hours, with incremental updates every 60 seconds |
| Storage | Stored in GCS |
| Encryption | Backup data is encrypted in transit and at rest |
| Retention | 90 days (7 days for CustomersDot database) |
| Loss prevention | Soft Delete enabled, with 7 day retention |
| Location/redundancy | Multi-region geo redundancy |
| Monitoring | All databases are continuously monitored to ensure successful backups, with alerts triggered for missing backups. |
| Restore validation | Regular restoration from disk snapshots and replaying WAL segments |
Git Repositories
| Area | Details |
|---|---|
| Backup frequency | Repositories are backed up hourly using block-level disk snapshots. |
| Storage | Stored as GCP Standard snapshots |
| Encryption | Snapshots are encrypted at rest |
| Retention | 14 days |
| Loss prevention | Retained after source disk deletion |
| Location/redundancy | Multi-region geo redundancy |
| Monitoring | All disks are monitored, with alerts triggered for missing snapshots |
| Restore validation | Conducted by randomly sampling disks and restoring recent snapshots. |
Object Storage
Data stored in Object Storage (GCS) benefits from Google’s 99.999999999% annual durability and multi-region bucket redundancy. To enhance data protection, Object Versioning and Soft Delete are enabled.
Automated restore validation is not required for Object Storage due to its inherent protections through versioning and soft delete.
Exceptions
Exceptions to this policy will be managed in accordance with the Information Security Policy Exception Management Process.
References
b731f1fe)
