Unverified Commit 5b72ea04 authored by anarcat's avatar anarcat
Browse files

move backups in the reference section 

Those instructions are better in "Reference" because it's about the
current design, "how things work", not "how to use them".

We would still need a backup/restore howto section, that said.
parent ec82bc0b

tsa/howto/gitlab.mdwn

+17 −12
Original line number Diff line number Diff line
@@ -57,18 +57,6 @@ lists: <tor-dev@lists.torproject.org> would be best. 
<!-- rebuild from scratch? not necessarily those procedures (e.g. see -->

<!-- "Installation" below but some pointers. -->



## Backups



There is a cronjob configured via the gitlab puppet monitor that runs every night

at 2.00 AM UTC



This will basically run `$ gitlab-backup ` and will create a tarball under:

`/srv/gitlab-backup/`



There is also a config backup job that makes sure to backup the content of

`/var/opt/gitlab/gitlab-rails/etc/`





# Reference



## Installation
@@ -272,6 +260,23 @@ There is no issue tracker specifically for this project, [File][] or 
<!-- describe how this service is monitored and how it can be tested -->

<!-- after major changes like IP address changes or upgrades -->



## Backups



There is a cronjob configured via the gitlab puppet monitor that runs

every night at 2:00AM UTC. This will basically run `$ gitlab-backup `

and will create a tarball under `/srv/gitlab-backup/`.



There is also a config backup job (in

`/etc/cron.d/gitlab-config-backup`) that makes sure to backup the

content of `/var/opt/gitlab/gitlab-rails/etc/` is backed up, because

that is not covered by the `gitlab-backup` command.



Another cron job purges backups older than two days, in

`/etc/cron.d/gitlab-rotate-backup`, so that we don't keep too many

copies on the server. It is assumed that the existing [[backups]]

system will pick up those copies and store them for our normal

rotation periods.



# Discussion



## Overview