mirror of
https://gitlab.archlinux.org/archlinux/infrastructure.git
synced 2024-09-28 13:31:55 +02:00
gitlab: Do away with generating tarball backups
Using GitLab's official backup tool takes too much time and, more importantly, space; /srv/gitlab is a bit over 430G but backing it up nearly exhausts its 1TB volume. As we're creating btrfs snapshots and backing those up with borg, it seems unnecessary to also create tarballs of the same data. GitLab's documentation mentions snapshots as a viable backup strategy, and to the restored system it should seem like recovering from a power loss. [1] https://docs.gitlab.com/ee/raketasks/backup_restore#alternative-backup-strategies
This commit is contained in:
parent
f6a0208e77
commit
0643978a10
@ -85,10 +85,6 @@ For PostgreSQL backups are made using pg_dump to `postgres_backup_dir`.
|
||||
|
||||
Restoring backups can be done with `pg_restore`. See also [official PostgreSQL docs](https://www.postgresql.org/docs/current/app-pgrestore.html).
|
||||
|
||||
### Gitlab
|
||||
|
||||
GitLab is backupped up using the `gitlab_backup` tool to `gitlab_backupdir`. See also [official GitLab docs](https://docs.gitlab.com/ee/raketasks/backup_restore.html).
|
||||
|
||||
## Adding a new server
|
||||
|
||||
Adding a new server to be backed up goes as follows:
|
||||
|
@ -1,6 +1,5 @@
|
||||
---
|
||||
filesystem: btrfs
|
||||
gitlab_backupdir: /srv/gitlab/data/backups
|
||||
additional_addresses: ["116.203.6.156/32", "2a01:4f8:c2c:5d2d::2/64"]
|
||||
wireguard_address: 10.0.0.5
|
||||
wireguard_public_key: EbZisS0fwM6B8Nkugy1lyox+A8L13hniucVIPVCK5R0=
|
||||
|
@ -56,10 +56,6 @@
|
||||
file: path={{ mysql_backup_dir }} state=directory owner=root group=root mode=0755
|
||||
when: mysql_backup_dir is defined
|
||||
|
||||
- name: install gitlab backup script
|
||||
template: src=backup-gitlab.sh.j2 dest=/usr/local/bin/backup-gitlab.sh owner=root group=root mode=0755
|
||||
when: inventory_hostname == "gitlab.archlinux.org"
|
||||
|
||||
- name: install systemd services for backup
|
||||
template: src={{ item }}.j2 dest=/etc/systemd/system/{{ item }} owner=root group=root mode=0644
|
||||
with_items:
|
||||
|
@ -1,15 +0,0 @@
|
||||
#!/bin/bash
|
||||
#
|
||||
# Script to backup Gitlab running in a Docker container
|
||||
#
|
||||
# https://docs.gitlab.com/omnibus/settings/backups.html#creating-backups-for-gitlab-instances-in-docker-containers
|
||||
#
|
||||
|
||||
backupdir="{{ gitlab_backupdir }}"
|
||||
|
||||
echo "emptying backup directory ${backupdir}"
|
||||
|
||||
# Verify that the gitlab_backupdir in ansible was defined, otherwise we will rm /* and remove the previous backup
|
||||
rm -r "${backupdir:?backup dir unset}/"*
|
||||
|
||||
docker exec gitlab gitlab-backup create STRATEGY=copy SKIP=tar GZIP_RSYNCABLE=yes
|
@ -1,10 +1,6 @@
|
||||
[Unit]
|
||||
Description=Borg backup
|
||||
|
||||
{% if inventory_hostname == "gitlab.archlinux.org" %}
|
||||
# The ordering relation defined below is important for the GitLab backups
|
||||
# because the offsite backup reuses the tarballs from this service's run.
|
||||
{% endif %}
|
||||
Wants=borg-backup-offsite.service
|
||||
Before=borg-backup-offsite.service
|
||||
|
||||
|
@ -45,12 +45,6 @@ if systemctl is-active mysqld || systemctl is-active mariadb; then
|
||||
/usr/local/bin/backup-mysql.sh || true
|
||||
fi
|
||||
|
||||
{# When backing up to offsite, reuse the existing tarballs from the previous backup #}
|
||||
{% if inventory_hostname == "gitlab.archlinux.org" and item['suffix'] != '-offsite' %}
|
||||
# Create tarball backups of various GitLab directories using the official backup tool
|
||||
systemctl is-active docker && /usr/local/bin/backup-gitlab.sh
|
||||
{% endif %}
|
||||
|
||||
if is_btrfs "$src"; then
|
||||
# List all btrfs submounts we want to backup, e.g. homedir.archlinux.org with "/ /home"
|
||||
list_of_btrfs_submounts=$(findmnt -Rl -o target,fstype,options / | grep btrfs | grep -v docker | grep -v "subvol=\/[[:alnum:]]" | cut -d ' ' -f1)
|
||||
|
@ -1 +0,0 @@
|
||||
gitlab_backupdir: /srv/gitlab/data/backups
|
Loading…
Reference in New Issue
Block a user