{"id":3237,"date":"2022-09-12T07:44:57","date_gmt":"2022-09-12T07:44:57","guid":{"rendered":"https:\/\/gitprotect.io\/blog\/?p=3237"},"modified":"2025-06-05T06:01:58","modified_gmt":"2025-06-05T06:01:58","slug":"gitlab-backup-to-s3","status":"publish","type":"post","link":"https:\/\/gitprotect.io\/blog\/gitlab-backup-to-s3\/","title":{"rendered":"GitLab Backup to S3"},"content":{"rendered":"\n

Businesses increasingly rely on S3 object storage for GitLab backups. Firms leverage the flexibility of the<\/strong> 3-2-1<\/strong><\/a>, 3-2-1-0, or even 4-3-2 strategy (or others) and improve disaster recovery options. At the same time, S3s lower the risk of potential data loss, contributing to operational cost optimization.<\/strong><\/p>\n\n\n\n\n\n\n\n

GitLab’s own guidance recommends<\/a> S3 storage (e.g., over NFS) for its performance and ease of integration.<\/p>\n\n\n\n

Given the rapid growth of GitLab repositories \u2013 containing source code, CI\/CD artifacts, and application data \u2013 S3 becomes a more logical and reliable choice. Its native features, such as cross-region replication (CRR) and object versioning, further bolster recovery options and ensure redundancy.<\/p>\n\n\n\n\n\n

S3 as a Shared Responsibility Model (SRM) support<\/strong><\/h2>\n\n\n\n

It’s worth remembering that cloud providers secure the underlying infrastructure, but the user
is responsible for securing and managing backups<\/a>. That involves enforcing encryption (including two-factor authentication, database encryption key), versioning, and policies for restricted access rights. And it’s hard to find an exception.<\/p>\n\n\n\n

Such an approach puts control over sensitive information directly in the hands of organizations. While this may sound challenging, it provides compliance and security strategies flexibility.<\/p>\n\n\n

\n
\"GitLab<\/figure><\/div>\n\n\n

Besides, scalability is the new black nowadays. Eliminating file-system complexity and supporting highly available storage solutions make S3 a natural fit for enterprise-level GitLab backup requirements and obligations.

It’s even more critical as weekly full and daily incremental backups are a common practice to balance storage costs and backup efficiency.<\/p>\n\n\n\n

The storage for your GitLab data backups<\/strong><\/h2>\n\n\n\n

The number of S3-compatible storage providers has grown in recent years. Along with increasing demand for scalable and cost-effective tools of this type, the growth of cloud adaptation and security needs follow.<\/p>\n\n\n\n

In addition to the major players listed below, niche cloud storage providers focus on specific business needs, such as data lakes or archival storage.<\/p>\n\n\n\n

Nonetheless, among the best-known S3 services, we can consider 5 top solutions.<\/p>\n\n\n\n

AWS S3<\/strong><\/h3>\n\n\n\n

AWS S3<\/a> is a highly scalable and secure object storage service by default. It integrates seamlessly with GitLab for backup and archival purposes. The storage offers lifecycle management, versioning, and cross-region replication for disaster recovery. Every Git user finds it easy to operate on.<\/p>\n\n\n\n

Azure Blob Storage<\/strong><\/h3>\n\n\n\n

Azure Blob<\/a> is ideal for GitLab users who are already working in the Microsoft ecosystem. It provides scalable storage and swift integration into Azure services. The Blob’s strong points are immutable storage for compliance and automated tiering for cost optimization.<\/p>\n\n\n\n

Google Cloud Storage<\/strong><\/h3>\n\n\n\n

With solid analytics and AI integrations, Google Cloud Storage<\/a> is great for high-performance GitLab backups. It supports automatic storage class transitions and multi-region redundancy for enhanced reliability. It’s worth noting that GCS is not an S3 solution in a sense but has very similar capabilities.<\/p>\n\n\n\n

Wasabi<\/strong><\/h3>\n\n\n\n

Wasabi<\/a> is a cost-effective S3-compatible storage option that offers predictable pricing with no egress or API fees. It’s a strong choice for GitLab users needing affordable long-term storage with high durability.<\/p>\n\n\n\n

Backblaze B2<\/strong><\/h3>\n\n\n\n

B2<\/a> is known for its simplicity and low cost. That’s a S3-compatible  storage with no egress fees. It’s well-suited for GitLab users needing inexpensive, reliable backup solutions with easy cloud service.<\/p>\n\n\n\n

After determining where and how you plan to utilize the S3 object storage capabilities, you must choose the right S3 provider for your GitLab-specific information.<\/p>\n\n\n\n

A quick overview of GitLab backup to S3<\/strong><\/h2>\n\n\n\n

In GitLab, the running backup process is based on the sudo gitlab-backup create command (the central part of the backup script).<\/p>\n\n\n\n

As a reminder, let us mention that it includes the following components:<\/p>\n\n\n

\n
\"GitLab<\/figure><\/div>\n\n\n

These are crucial for GitLab instance backup, enabling easy restoration from the backup directory.<\/p>\n\n\n\n

Backup archive in S3<\/strong><\/h3>\n\n\n\n

At a GitLab level, to configure (reconfigure) S3 requires accessing and editing the configuration file: <\/p>\n\n\n\n

\/etc\/gitlab\/gitlab.rb<\/strong><\/p>\n\n\n\n

The configuration may look like the following:<\/p>\n\n\n\n

gitlab_rails ['backup_upload_connection'] = {\n\n\"provider\" => \"AWS\",\n\n\"region\" => \"your-region\", # e.g., \"us-west-1\"\n\n\"aws_access_key_id\" => \"your-access-key-id\",\n\n\"aws_secret_access_key\" => \"your-secret-access-key\"\n\n}\n\ngitlab_rails['backup_upload_remote_directory'] = 'your-s3-bucket-name'<\/code><\/pre>\n\n\n\n
Thinking about an upload, you can choose a slightly different approach. Here is an example script:<\/p>\n\n\n\n
gitlab_rails['backup_upload_enabled'] = true\n\ngitlab_rails['backup_upload_connection'] = {\n\n\"provider\" => \"AWS\", \"aws_access_key_id\" => \"YOUR_ACCESS_KEY\", \n\n\"aws_secret_access_key\" => \"YOUR_SECRET_KEY\",\n\n\"region\" => \"YOUR_REGION\"\n\n}\n\ngitlab_rails['backup_upload_remote_directory'] = 'your-backup-bucket'<\/code><\/pre>\n\n\n\n
After each backup, you should check your S3 bucket to confirm that you uploaded the backup successfully.<\/p>\n\n\n\n
You can also configure the backup path and retention by setting the policy:<\/p>\n\n\n\n
gitlab_rails['backup_path'] = \"\/var\/opt\/gitlab\/backups\"  \n\n# Local directory to store backups before upload\n\ngitlab_rails['backup_keep_time'] = 604800   # Time in seconds (1 week)<\/code><\/pre>\n\n\n\n
Then, you use a simple command to create a backup:<\/p>\n\n\n\n
sudo gitlab-backup create<\/code><\/pre>\n\n\n\n
Of course, there is an option to automate backup with cron jobs. For example, to back up GitLab at 5 AM daily and upload it to S3, use the following line:<\/p>\n\n\n\n
0 5  * \/opt\/gitlab\/bin\/gitlab-backup create CRON=1<\/code><\/pre>\n\n\n\n
Restoring GitLab backups from S3<\/strong><\/h3>\n\n\n\n
You need three default steps to bring back your GitLab backup stored in S3 storage.<\/p>\n\n\n\n
    \n
  1. Go to your S3 bucket, select the required tar file (*.tar), and download it for your GitLab server.
    <\/li>\n\n\n\n
  2. Restore the backup.<\/li>\n<\/ol>\n\n\n\n