|
|
|
## Gitlab (sharing-codeability.uibk.ac.at & codeability-git.uibk.ac.at)
|
|
|
|
|
|
|
|
The backup strategy developed for Gitlab is composed by 2 phases:
|
|
|
|
|
|
|
|
1. Gitlab backup creation
|
|
|
|
|
|
|
|
*Based on [https://docs.gitlab.com/ee/raketasks/backup_restore.html](https://docs.gitlab.com/ee/raketasks/backup_restore.html)*
|
|
|
|
|
|
|
|
The following Cronjob, scheduling the creation of a backup archive and copying the configuration directory daily at 2AM, has been added.
|
|
|
|
|
|
|
|
```
|
|
|
|
0 2 * * * docker exec -t gitlab bash -c "gitlab-backup create STRATEGY=copy CRON=1;cp -r /etc/gitlab /var/opt/gitlab/config_backup"
|
|
|
|
```
|
|
|
|
|
|
|
|
As both VMs already have the backup destination path mounted, or contained in mounted volumes, these files are persisted and can be directly accessed from outside the container. The path to the mounted files/volume can be retrieved using `docker inspect <gitlab_container_name>` under the 'Mounts' section. (Search for `gitlab_data` volume)
|
|
|
|
|
|
|
|
2. Gitlab backup replication
|
|
|
|
|
|
|
|
To further secure the Gitlab backup files, an additional Cronjob, scheduled daily at 3AM and replicating the files generated in Phase 1 to a directory *(or link to a mounted NFS directory)* in the root file system, has been added. This avoids potential loss of data in case of accidental removal/corruption of the Gitlab's volumes.
|
|
|
|
|
|
|
|
```
|
|
|
|
0 3 * * * BASH_ENV=/root/.bashrc /gitlab_backup_script.sh
|
|
|
|
```
|
|
|
|
|
|
|
|
The replicated backup files can be found at `/gitlab-backup` of both VMs.
|
|
|
|
|
|
|
|
3. Gitlab monthly replication
|
|
|
|
|
|
|
|
To address the problem that bugs or inconsistencies might go unnoticed for more than a week, a monthly backup strategy has been integrated. As it wouldn't be possible to ensure a monthly at any time without a backup retention time of a month, another 'best effort' approach has been used.
|
|
|
|
|
|
|
|
Using the following Cronjob, at each 1st day of the month, the oldest backup is replicated into a separate directory (`/gitlab-backup/monthly-archive`) and stored until the next monthly rotation. Therefore, the 'monthly replication' in this case, will be at least 7 days old and at most one month old.
|
|
|
|
|
|
|
|
```
|
|
|
|
0 3 1 * * BASH_ENV=/root/.bashrc /gitlab_monthly_backup_script.sh
|
|
|
|
```
|
|
|
|
|
|
|
|
### Restore
|
|
|
|
|
|
|
|
Restoring the Gitlab container from a backup is quite straight forward:
|
|
|
|
|
|
|
|
- [Restore prerequisites](https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-prerequisites)
|
|
|
|
- [Restore for Docker image](https://docs.gitlab.com/ee/raketasks/backup_restore.html#restore-for-docker-image-and-gitlab-helm-chart-installations)
|
|
|
|
```
|
|
|
|
# Start a fresh Gitlab instance
|
|
|
|
docker run -it <custom_configurations> gitlab/gitlab-ce:<version>
|
|
|
|
|
|
|
|
# Stop the processes that are connected to the database
|
|
|
|
docker exec -it <name of container> gitlab-ctl stop puma
|
|
|
|
docker exec -it <name of container> gitlab-ctl stop sidekiq
|
|
|
|
|
|
|
|
# Verify that the processes are all down before continuing
|
|
|
|
docker exec -it <name of container> gitlab-ctl status
|
|
|
|
|
|
|
|
# Run the restore. NOTE: "_gitlab_backup.tar" is omitted from the name
|
|
|
|
docker exec -it <name of container> gitlab-backup restore BACKUP=11493107454_20xx_xx_xx_xx.x.x-ce
|
|
|
|
|
|
|
|
# Restart the GitLab container
|
|
|
|
docker restart <name of container>
|
|
|
|
|
|
|
|
# Check GitLab
|
|
|
|
docker exec -it <name of container> gitlab-rake gitlab:check SANITIZE=true
|
|
|
|
```
|
|
|
|
|
|
|
|
#### Further details
|
|
|
|
|
|
|
|
* The backup lifetime of Gitlab backups have been set to 7 days (can be changed in `/etc/gitlab/gitlab.rb` - `gitlab_rails['backup_keep_time']`)
|
|
|
|
|
|
|
|
___ |
|
|
\ No newline at end of file |
