Self-Managed Administration: Configuration, Email, Object Storage, Backups, Restore, and Maintenance: Configuration, Design Choices, and Tradeoffs

1. From commands to design

Lesson 2 showed that recovery is a dependency graph. Design determines how large that graph becomes. A single Linux-package node is operationally simple but concentrates failure; external object storage can improve scalability but adds bucket policy, network, consistency, and separate-backup obligations. Self-Managed freedom is therefore coupled to platform-engineering ownership.

2. GitLab.com versus Self-Managed operational responsibility

3. Local storage versus external object storage

Local disk reduces moving parts and is suitable for small disposable/single-node environments, but capacity and durability are tied closely to the node/storage system. External object storage decouples large blobs and is generally preferred for larger setups, but each bucket and credential becomes part of recovery design. The consolidated GitLab object-store configuration reduces duplicated connection configuration across supported object types.

4. Backup frequency is a business decision expressed as RPO/RTO

RPO is the maximum acceptable data loss window. RTO is the target time to restore service. A daily backup cannot honestly satisfy a one-hour RPO. A fast backup tool does not prove a two-hour RTO if operators first need to rebuild the exact GitLab version, recover secrets, recreate bucket IAM, and discover storage names.

# Example recovery objective fixture (not a universal recommendation)
rpo_minutes=60
rto_minutes=180
application_backup_frequency=hourly
config_backup_on_change=true
secrets_backup_on_change=true
object_storage_versioning_or_backup=true
restore_drill_frequency=quarterly

5. Single-node simplicity versus external services

External PostgreSQL, Redis, Gitaly nodes, registry metadata database, object stores, and load balancers can improve capacity and availability, but they split recovery across systems. A backup tool may require PgBouncer-specific parameters; repository storage names must match; object-store data and registry metadata should be captured close enough in time to reconstruct a coherent state. Chapter 31 will expand this into HA and disaster recovery.

6. Mail design: delivery is security-sensitive infrastructure

SMTP is not just “notifications.” It participates in account recovery and user workflows. Use authenticated TLS correctly, validate certificates, configure SPF/DKIM/DMARC for production domains, and keep credentials in encrypted configuration or an appropriate secret store. GitLab documents STARTTLS and SMTPS as mutually exclusive modes; enabling both can create a clear diagnostic failure rather than “silent mail instability.”

7. Backup policy: scope, separation, retention, and proof

A production policy should identify application data, config/secrets, certificates/SSH host keys, external object storage, and any external database/registry-specific backup method. Retain multiple generations, keep at least one failure-domain-separated copy, encrypt backups at rest/in transit, restrict restore credentials more strongly than read-only backup credentials where possible, and record deletion/retention ownership.

8. Maintenance Mode versus explicit downtime

Maintenance Mode is useful when Premium/Ultimate is available because it reduces external writes while allowing many reads. It is not a substitute for understanding what internal jobs still change state. Free operators can schedule explicit downtime and stop/write-quiesce services according to the backup method. Choose based on consistency requirement and availability objective, not on convenience.

9. Worked decision table

10. Anti-patterns to reject

• “The VM snapshot is our backup” without application consistency or restore testing.
• Keeping gitlab-secrets.json beside an unencrypted database backup with the same access control.
• Moving to object storage but leaving backup ownership undefined.
• Using a single permanent root/cloud key for routine backup and restore.
• Measuring RTO from the moment the restore command starts rather than incident declaration to verified service.
• Adding external services before there is monitoring, ownership, and a recovery runbook.

Knowledge check

11. Lesson summary and bridge

Architecture is recovery policy made physical. Lesson 4 now stress-tests the design against the failures that most often expose false confidence: missing secrets, incompatible targets, wrong buckets, SMTP/TLS mistakes, and unsafe maintenance.

Primary sources and version notes

These lessons were finalized against current official GitLab documentation on 2026-08-22 and GitLab 19.3. Self-Managed commands and file locations depend on installation method. Re-check the documentation for the exact version, topology, package/chart, and storage architecture before production administration or recovery.

• GitLab 19.3 release
• Administer GitLab
• Configure GitLab
• Back up GitLab
• Restore GitLab
• Linux package backup configuration
• Docker backup
• Helm chart backup and restore
• Object storage
• SMTP settings
• Encrypted configuration
• Health check
• Maintenance Mode
• Maintenance Rake tasks
• Integrity check Rake tasks
• Repository checks