forgejo-backup #89

Open
Tormod wants to merge 9 commits from forgejo-backup into main
Member

Lagt til backup av database og repo data. Måtte endre ProtectSystem til full i common/roles/backup/templates/backup.service.j2. med ProtectSystem satt til strict fikk jeg problemer med at restic ikke fikk mountet riktig directories for å ta backup.

Lagt til backup av database og repo data. Måtte endre ProtectSystem til full i `common/roles/backup/templates/backup.service.j2`. med ProtectSystem satt til strict fikk jeg problemer med at restic ikke fikk mountet riktig directories for å ta backup.
@ -10,3 +10,3 @@
IOSchedulingClass=idle
PrivateTmp=true
ProtectSystem=strict
ProtectSystem=full

Hvilken feilmelding fikk du med ProtectSystem=strict? Rart at dette funker på Loomio, men ikke med Forge.

Hvilken feilmelding fikk du med ProtectSystem=strict? Rart at dette funker på Loomio, men ikke med Forge.
Author
Member

Oct 13 19:18:08 kode backup.sh[857596]: 2026-10-13 19:18:08 - Starting backup Oct 13 19:18:08 kode backup.sh[857596]: 2026-10-13 19:18:08 - [Pre-backup] podman-compose -f "/opt/deploy/compose.yaml" exec -T db pg_dump -O -U forgejo -Fc forgejo -f "/pgdumps/forgejo.dump" Oct 13 19:18:09 kode backup.sh[857606]: Error: configure storage: open /var/lib/containers/storage/storage.lock: read-only file system

Sånn jeg skjønner det er grunnen til at jeg får det at jeg importerer role: backup med backup_pre_commands: - podman-compose -f "/opt/deploy/compose.yaml" exec -T db pg_dump -O -U forgejo -Fc forgejo -f "/pgdumps/forgejo.dump". ProtectSystem=strict setter /var til read-only, så det failer.

Så vidt jeg kan skjønne skjer ikke dette med Loomio fordi Loomio dumper databasen med docker, og ikke podman.

En løsning jeg tenkte på nå, som kanskje er bedre siden den ikke går på bekostning av herding er å appende /var (og kanskje også /run litt usikker på om podman trenger den) til ReadWritePaths= på linje 13

`Oct 13 19:18:08 kode backup.sh[857596]: 2026-10-13 19:18:08 - Starting backup Oct 13 19:18:08 kode backup.sh[857596]: 2026-10-13 19:18:08 - [Pre-backup] podman-compose -f "/opt/deploy/compose.yaml" exec -T db pg_dump -O -U forgejo -Fc forgejo -f "/pgdumps/forgejo.dump" Oct 13 19:18:09 kode backup.sh[857606]: Error: configure storage: open /var/lib/containers/storage/storage.lock: read-only file system` Sånn jeg skjønner det er grunnen til at jeg får det at jeg importerer `role: backup` med ` backup_pre_commands: - podman-compose -f "/opt/deploy/compose.yaml" exec -T db pg_dump -O -U forgejo -Fc forgejo -f "/pgdumps/forgejo.dump"`. `ProtectSystem=strict` setter `/var` til read-only, så det failer. Så vidt jeg kan skjønne skjer ikke dette med Loomio fordi Loomio dumper databasen med docker, og ikke podman. En løsning jeg tenkte på nå, som kanskje er bedre siden den ikke går på bekostning av herding er å appende `/var` (og kanskje også `/run` litt usikker på om podman trenger den) til `ReadWritePaths=` på linje 13

En løsning jeg tenkte på nå, som kanskje er bedre siden den ikke går på bekostning av herding er å appende /var (og kanskje også /run litt usikker på om podman trenger den) til ReadWritePaths= på linje 13

Dette høres bedre ut! Takk for forklaringen.

>En løsning jeg tenkte på nå, som kanskje er bedre siden den ikke går på bekostning av herding er å appende /var (og kanskje også /run litt usikker på om podman trenger den) til ReadWritePaths= på linje 13 Dette høres bedre ut! Takk for forklaringen.
@ -16,3 +14,4 @@
- Configure firewall in hypervisor
- Setup Email
- setup runner
- setup anubis (or similar crawler protection)

Kan vi legge til en TODO for å oppgradere Postgres til versjon 18 og Forgejo til 16?

Kan vi legge til en TODO for å oppgradere Postgres til versjon 18 og Forgejo til 16?

Jeg har fått opp en PR med Anubis om du ønsker å ta en titt #90

Jeg har fått opp en PR med Anubis om du ønsker å ta en titt https://forge.hornwitser.no/datakollektivet/systemer/pulls/90
@ -29,0 +37,4 @@
backup_dir: /opt/backups
backup_paths:
- /opt/deploy/pgdumps
- /opt/deploy/forgejo

Dette er hvor repo data er lagret?

Dette er hvor repo data er lagret?
Owner

Sånn ca. Støtter at denne bruker templating {{deploy_dir}}/forgejo e.l.

Sånn ca. Støtter at denne bruker templating {{deploy_dir}}/forgejo e.l.
Author
Member

@gingermusketeer Blant annet. repo data er i forgejo/git/repositories. Valgte å være mer inkluderende i hva jeg tok backup av og også ta med ssh nøkler, logger, avatarer, arkiver o.l.

Litt usikker på om det er for mye, men tenkte at det er eventuelt bedre å ta med for mye enn for lite.

@gingermusketeer Blant annet. repo data er i forgejo/git/repositories. Valgte å være mer inkluderende i hva jeg tok backup av og også ta med ssh nøkler, logger, avatarer, arkiver o.l. Litt usikker på om det er for mye, men tenkte at det er eventuelt bedre å ta med for mye enn for lite.

Hva slags logger er det vi ha backups på? Vi har en log retention policy i logs role som er maks 90 dager.

Hva slags logger er det vi ha backups på? Vi har en log retention policy i `logs` role som er [maks 90 dager](https://forge.hornwitser.no/datakollektivet/systemer/src/commit/0910038379ef226b29d01ac01fe1d829e3d0c71f/common/roles/logs/tasks/main.yaml#L12).
@ -13,0 +12,4 @@
restic_repository: ENC[AES256_GCM,data:5Zof1E1ggQTy1BqV1iLk7UmRvHcC+xH4G5yR1HYU5YJUYyVijIUZ2EeuAWe+,iv:k8lCe9PE0hGQZ454vHW+9Dkq/KeDEt4OYYaPdz2+WCk=,tag:fxdef3YHfmrzU3Kx61Kt9w==,type:str]
smtp:
access_key_id: ENC[AES256_GCM,data:p9BRzLetzyflOytPBvsfePcUTaM=,iv:WFyWyzX7a9t5ftEiO+S3r8LpOHX9EzUiJqBVG2lfoo0=,tag:9eRM8xklm0P5iM5rt6Dwvw==,type:str]
secret_access_key: ENC[AES256_GCM,data:N4Vc3s6BbspoR2EbGqlfQUswd/5X1Tp5Rpl2/oa4ICyw9GE+,iv:OkzkJuwmSlMzDMWEk93uOjtm1hSVciKv5UgbeuTCCso=,tag:anAIcjMhtbEfT8BpYaSuzQ==,type:str]

Vet du hvorfor vi har access_key_id og secret_access_key to ganger men restic_* bare en gang?

Vet du hvorfor vi har `access_key_id` og `secret_access_key` to ganger men `restic_*` bare en gang?
Author
Member

Det er nok fordi de to siste linjene er til SMTP. Det har egentlig ingenting med denne PR-en å gjøre, men fikk SMTP credentials av Alex samtidig som restic credentials. Tenkte det var like greit å få de inn i versjonskontroll asap

Det er nok fordi de to siste linjene er til SMTP. Det har egentlig ingenting med denne PR-en å gjøre, men fikk SMTP credentials av Alex samtidig som restic credentials. Tenkte det var like greit å få de inn i versjonskontroll asap

Sorry så det ikke før nå. Det er litt vanskelig å lese denne fil!

Sorry så det ikke før nå. Det er litt vanskelig å lese denne fil!
gingermusketeer marked this conversation as resolved
Owner

Kan jeg legge til en liten request? Si ifra om du ønsker at det tas et annet sted.

Jeg er ikke så fan av at Forgejo konfigurasjon har lekket ut av "kode" mappen til https://forge.hornwitser.no/datakollektivet/systemer/src/branch/main/group_vars/staging.yaml her.

Men er du åpen for å flytte group_vars/config til f.eks. kode/playbooks/group_vars mappen? Jeg er litt usikker på hva som plukkes opp automatisk. Men om det er i playbooks mappen blir det kanskje det?

Jeg foretrekker locality og misliker tanken på at man må følge med på endringer på delte filer eller så kan man få overraskelser i sine deploy scripts.

Kan jeg legge til en liten request? Si ifra om du ønsker at det tas et annet sted. Jeg er ikke så fan av at Forgejo konfigurasjon har lekket ut av "kode" mappen til https://forge.hornwitser.no/datakollektivet/systemer/src/branch/main/group_vars/staging.yaml her. Men er du åpen for å flytte group_vars/config til f.eks. kode/playbooks/group_vars mappen? Jeg er litt usikker på hva som plukkes opp automatisk. Men om det er i playbooks mappen blir det kanskje det? Jeg foretrekker locality og misliker tanken på at man må følge med på endringer på delte filer eller så kan man få overraskelser i sine deploy scripts.
Author
Member

@alexanrf Litt usikker på hvorfor jeg ikke bare kan replye til kommentaren din. Uansett, ja kan godt flytte group_vars inn i kode. Ser at group_vars under playbooks også blir med automatisk. Poenget for min del var å få til å kunne endre fra prod og staging miljø uten å måtte endre i koden, så jeg gjorde det med inventory groups i inventory.yaml. Umiddelbart bare virket det mest oversiktlig å legge group variables i en delt mappe, men ser også argumentet med locality og at det kan bli mindre oversiktlig på sikt.

@alexanrf Litt usikker på hvorfor jeg ikke bare kan replye til kommentaren din. Uansett, ja kan godt flytte group_vars inn i kode. Ser at `group_vars` under `playbooks` også blir med automatisk. Poenget for min del var å få til å kunne endre fra prod og staging miljø uten å måtte endre i koden, så jeg gjorde det med inventory groups i `inventory.yaml`. Umiddelbart bare virket det mest oversiktlig å legge group variables i en delt mappe, men ser også argumentet med locality og at det kan bli mindre oversiktlig på sikt.
gingermusketeer left a comment

Ser bra ut men ønsker at vi bruker ProtectSystem=strict og at vi unngår logger i backups

Ser bra ut men ønsker at vi bruker `ProtectSystem=strict` og at vi unngår logger i backups
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin forgejo-backup:forgejo-backup
git switch forgejo-backup
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
datakollektivet/systemer!89
No description provided.