# Lokal Backup med tar + rsync — VM til VM
> **Topologi: Arbejdsstation (VM1) → Backup-server (VM2)**
## Backup øvelse / opgave?
- [ ] Forstå topologien og konfigurere netværk i VirtualBox/VMware
- [ ] Opsætte SSH-nøglebaseret autentificering med `~/.ssh/config`
- [ ] Bruge `tar` til at pakke og komprimere mapper og sammenligne algoritmer
- [ ] Verificere backup-integritet med `sha256sum`
- [ ] Overføre arkiv og checksum fra VM1 til VM2 med `rsync`
- [ ] Forstå hvad der sker når noget fejler — og hvem der får besked
- [ ] Automatisere hele processen med `cron` og logrotation
## Lab Journal og Peer Review — Gennemgående opgave
> [!info] Hvad er dette?
> Ud over de tekniske øvelser skal du gennem hele workshoppen føre en **lab journal**. Journalen er en løbende dokumentation af dit arbejde og udgør grundlaget for en senere **peer review**
### Hvad du skal gøre
**Undervejs i alle øvelser**
- Udfyld lab journalen løbende, ikke bagefter så har du glemt det.
- Tag screenshots af kommandoer, output og fejlmeddelelser
- Dokumentér fejl og løsninger. Husk, de er mindst ligeså værdifulde som succes
- Besvar refleksionsspørgsmålene i hvert afsnit
**Topologi-diagram (færdigt inden Del 3):**
Tegn et diagram over din opsætning. Det skal vise begge VMs med hostname og IP, begge netværksadaptere, dataflow-retning med protokol, backup-mappen på VM2, og SSH-config-aliaset `vm2`
---
# Del 1 — Netværksopsætning
Denne øvelse er centreret omkring et simpel netværk og opsætning bestående af 2 virtuelle maskiner som begge er placeret i samme hypervisor. VM1 er vores arbejdsmaskine / labpc og må derfor gerne have en GUI / Desktop. Denne VM kan med fordel også have to netkort (NIC). En som er koblet på et NAT netværk sådan at den har adgang til internettet via jeres host pc. NIC nummer 2 skal være forbundet til VM2 med et netværk som kun indeholde disse to maskiner. Du kan benytte Host-only netværk og drage nytte af DHCP servicen som uddeler IP adresser direkte fra hypervisoreren.
![[backup_topologi_tavle.png]]
## Trin 1 — Konfigurer Host-Only netværk
**I VirtualBox — opret Host-Only netværk (gøres én gang):**
1. Åbn VirtualBox → **Filer** → **Netværkshåndtering** (`Ctrl+H`)
2. Klik på **Host-Only Networks**-fanen → **Opret**
3. `vboxnet0` oprettes med adresse `192.168.56.1/24`
4. Sørg for at **DHCP-server** er aktiveret
**I VMware workstation (opret et custom net)**
1. Edit → Virtual Network Editor
2. Add network, find et nummer (husk ikke 0,1,8)
3. Vælg Host-only
4. Giv dette netværk et passende fx. `10.10.42.0/24`
5. Slå DHCP service til.
**Tilføj Adapter 2 til begge VMs:**
1. Vælg VM → **Indstillinger** → **Netværk** → **Adapter 2**
2. Tilsluttet til: **Host-Only Adapter** — Navn: `vboxnet0` → **OK**
3. Gentag for den anden VM
> [!tip] Adapter 1 bevares som NAT
> På VM1, lad Adapter 1 stå som **NAT** — det sikrer fortsat internetadgang. Adapter 2 bruges udelukkende til intern VM-kommunikation.
---
## Trin 2 — Find IP-adresser og test ping
```bash
# Kør på begge VMs — find Host-Only IP
ip -c addr show
# Test fra VM1
ping -c 4 10.10.42.20
```
| VM | Rolle | Eksempel-IP |
| --- | ----------------------------- | -------------- |
| VM1 | Arbejdsstation (Lubuntu/Mint) | `10.10.42.100` |
| VM2 | Backup-server (Ubuntu Server) | `10.10.42.20` |
*Erstat med dine faktiske adresser i alle kommandoer herunder.*
> [!warning] Hvis ping fejler
> - Aktiver adapteren manuelt: `sudo ip link set enp0s8 up`
> - Tjek at DHCP er aktivt på `vboxnet0` i VirtualBox Netværkshåndtering
---
# Del 2 — SSH-opsætning
## Trin 3 — Installer SSH-server på VM2
Dette trin er kun nødvendig hvis du under installationen ikke valgte at installere en SSH server på din Ubuntu server. Det kræver adgang til internettet, så du skal derfor skifte netværk til NAT for at kunne udføre denne opgave.
```bash
# På VM2
sudo apt update && sudo apt install openssh-server -y
sudo systemctl enable --now ssh
sudo systemctl status ssh
# Forventet: Active: active (running)
```
Husk at skift netværk tilbage og gentage [[#Trin 2 — Find IP-adresser og test ping]]]
---
## Trin 4 — Generer SSH-nøglepar på VM1
```bash
# På VM1 — generer et Ed25519 nøglepar
ssh-keygen -t ed25519 -C "vm1-backup-key"
# Tryk Enter tre gange (standardplacering, ingen passphrase)
# Privat nøgle: ~/.ssh/id_ed25519 ← MÅ ALDRIG deles
# Offentlig nøgle: ~/.ssh/id_ed25519.pub ← kopieres til VM2
cat ~/.ssh/id_ed25519.pub
```
> [!danger] Den private nøgle er som et kodeord
> `~/.ssh/id_ed25519` må aldrig deles, kopieres til andre maskiner eller checkes ind i Git. Som i aldrig nogensinde! Basta!
---
## Trin 5 — Kopiér offentlig nøgle til VM2
```bash
# På VM1 — eneste gang du taster password
ssh-copy-id
[email protected]
```
---
## Trin 6 — Opret `~/.ssh/config` (anvendes ofte i industrien)
I stedet for at skrive `
[email protected]` i alle kommandoer og scripts, definerer vi et alias på VM1. Det er standard praksis og reducerer fejl markant — IP-adressen skal kun ændres ét sted.
```bash
# På VM1 — opret SSH config-filen
nano ~/.ssh/config
```
Indsæt:
```
Host vm2
HostName 10.10.42.20
User [brugernavn]
IdentityFile ~/.ssh/id_ed25519
```
```bash
# Sæt korrekte rettigheder (påkrævet af SSH)
chmod 600 ~/.ssh/config
# Test — nu fungerer dette i stedet for den lange version:
ssh vm2
exit
# Og rsync kan nu skrives som:
# rsync -avh ~/arbejde/ vm2:~/backups/
```
> [!info] Fordelen ved `~/.ssh/config`
> Alle scripts og kommandoer bruger nu `vm2` som destination. Hvis IP-adressen ændrer sig, retter du kun ét sted — i config-filen. Det gælder SSH, rsync, SCP og alle andre SSH-baserede værktøjer.
---
# Del 3 — tar: Arkivering og komprimering
## Hvad er tar — og hvorfor bruge det?
`tar` (Tape ARchive) samler mange filer og mapper til **ét enkelt arkiv**. Det løser et problem rsync ikke håndterer alene: **atomicitet**.
> [!info] Problemet med at overføre mapper direkte
> Når rsync kopierer en mappe med hundredvis af filer, kan filerne ændre sig undervejs — du risikerer en inkonsistent backup, hvor nogle filer er fra "før" og andre fra "efter" en ændring.
>
> Med tar tages et **snapshot** af hele mappen på ét tidspunkt. Resultatet er ét enkelt, komprimeret arkiv der kan verificeres og overføres som en samlet enhed.
| Behov | Kun tar | Kun rsync | tar + rsync ✓ |
|---|---|---|---|
| Komprimering | ✓ | Delvist (-z) | ✓ |
| Enkelt fil at håndtere | ✓ | ✗ | ✓ |
| Krypteret overførsel | ✗ | ✓ (SSH) | ✓ (SSH) |
| Atomisk snapshot | ✓ | ✗ | ✓ |
| Delta-overførsel | ✗ | ✓ | ✓ |
| Verificerbar integritet | ✓ (med sha256sum) | ✗ | ✓ |
---
## tar-flag
| Flag | Beskrivelse |
|---|---|
| `-c` | **Create** — opret nyt arkiv |
| `-x` | **eXtract** — udpak arkiv |
| `-t` | **lisT** — vis indhold uden at udpakke |
| `-v` | **Verbose** — vis filnavne |
| `-f` | **File** — angiv arkivfilens navn (skal altid med) |
| `-z` | **gzip** — komprimér med gzip (`.tar.gz`) |
| `-j` | **bzip2** — komprimér med bzip2 (`.tar.bz2`) |
| `-J` | **xz** — komprimér med xz (`.tar.xz`) |
| `-C` | **Change directory** — skift mappe inden pakning |
| `--exclude` | Udelad filer/mapper der matcher mønster |
> [!tip] Huskeregel: create/extract/list + verbose + file
> `tar -cvf arkiv.tar mappe/` ← opret
> `tar -xvf arkiv.tar` ← udpak
> `tar -tvf arkiv.tar` ← vis indhold
---
## Trin 7 — Opret testdata på VM1
```bash
# På VM1
mkdir -p ~/arbejde/projekter ~/arbejde/dokumenter ~/arbejde/billeder
mkdir -p ~/arbejde/.cache ~/arbejde/tmp # ← disse vil vi IKKE have med i backup
echo "Projekt Alpha — statusrapport v2" > ~/arbejde/projekter/alpha.txt
echo "Projekt Beta — igangværende" > ~/arbejde/projekter/beta.txt
echo "Mødereferat 2025-06-10" > ~/arbejde/dokumenter/referat.txt
echo "Konfiguration: env=produktion" > ~/arbejde/dokumenter/config.txt
date > ~/arbejde/dokumenter/sidst_opdateret.txt
echo "midlertidig fil" > ~/arbejde/tmp/temp.txt
echo "cache-data" > ~/arbejde/.cache/data.bin
cd ~/arbejde/dokumenter
wget https://www.gutenberg.org/ebooks/4686.txt.utf-8
# Simulér en større fil (1 MB)
dd if=/dev/urandom of=~/arbejde/billeder/foto.bin bs=1M count=1 2>/dev/null
find ~/arbejde -type f -ls
```
---
## Trin 8 — Sammenlign komprimeringsalgoritmer
Eksperimenter med algoritme, undersøg og *måle* forskellen. Det giver en konkret forståelse for tradeoff-tænkning.
```bash
# På VM1 — pak med tre algoritmer og mål tid og størrelse
mkdir -p /tmp/komptest
echo "--- gzip ---"
time tar -czf /tmp/komptest/test_gzip.tar.gz -C ~ arbejde/
echo "--- bzip2 ---"
time tar -cjf /tmp/komptest/test_bzip2.tar.bz2 -C ~ arbejde/
echo "--- xz ---"
time tar -cJf /tmp/komptest/test_xz.tar.xz -C ~ arbejde/
# Sammenlign filstørrelser
echo ""
echo "--- Resultater ---"
ls -lh /tmp/komptest/
# Ryd op
rm -rf /tmp/komptest
```
> [!info]- Hvad kan du forventer at se?
> **gzip:** Hurtigst, mindst komprimering
> **bzip2:** Langsommere, typisk 10-15% mindre end gzip
> **xz:** Langsomst, bedst komprimering — op til 30-40% mindre end gzip
>
> **Til daglig backup på et lokalt netværk:** gzip (`-z`) er det rigtige valg — det er hurtigt og understøttes overalt.
---
## Trin 9 — Opret backup-arkiv med --exclude
Nu bruger vi vores viden til at pakke `~/arbejde/` — men vi udelader mapper der ikke giver forretningsværdi:
```bash
# På VM1
mkdir -p /tmp/tar_test
# Tidsstempel i filnavnet: dato + klokkeslæt
# Forhindrer at to kørsler samme dag overskriver hinanden
TIMESTAMP=$(date +%Y-%m-%d_%H-%M)
ARKIV="/tmp/tar_test_${TIMESTAMP}.tar.gz"
tar -czvf $ARKIV \
--exclude='tmp' \
--exclude='.cache' \
--exclude='*.tmp' \
-C ~ arbejde/
# Verificer resultatet
ls -lh /tmp/*.tar.gz
```
\* virker som wildcard
> [!warning] Tidsstempel frem for kun dato
> `arbejde_2025-06-10.tar.gz` vil blive overskrevet hvis scriptet køres to gange samme dag.
> `arbejde_2025-06-10_14-30.tar.gz` er unikt og giver en naturlig point-in-time historik.
---
## Trin 10 — Inspicér og test arkivet
```bash
# List indhold uden at udpakke
tar -tzvf /tmp/tar_test_*.tar.gz
# Verificer at .cache og tmp IKKE er med
tar -tzvf /tmp/tar_test_*.tar.gz | grep -E "cache|tmp"
# Ingen output = de er korrekt ekskluderet ✓
```
**Test udpakning lokalt — inden du stoler på backup-arkivet:**
```bash
mkdir -p /tmp/restore_test
tar -xzvf /tmp/tar_test_*.tar.gz -C /tmp/restore_test
# Ingen output = filerne er identiske ✓
diff -r ~/arbejde/ /tmp/restore_test/arbejde/ \
--exclude='.cache' --exclude='tmp'
# prøv
diff -r ~/arbejde/ /tmp/restore_test/arbejde/
rm -rf /tmp/restore_test
```
> [!success] En backup er kun værd noget, hvis restore virker
> Test altid udpakning lokalt inden overførslen. `diff -r` uden output bekræfter at arkivet er intakt.
---
## Tid til refleksion
> [!note] Diskutér med sidemanden inden I fortsætter
> I har nu et verificeret backup-arkiv lokalt på VM1.
>
> **Spørgsmål til diskussion:**
> 1. Hvad er RPO og RTO for jeres opsætning *lige nu* — inden VM2 er med?
> 2. Hvad ændrer sig for RPO og RTO, når arkivet kopieres til VM2?
> 3. Overholder I 3-2-1-reglen med den nuværende opsætning? Hvad mangler?
---
# Del 4 — Integritet med sha256sum
En backup du ikke kan verificere er en backup du ikke kan stole på. `sha256sum` genererer et fingeraftryk (hash) af arkivfilen. Hvis en eneste bit er ændret under overførslen, vil hashen ikke matche.
## Trin 11 — Generer og verificer checksum
```bash
# På VM1 — generer checksum-fil for arkivet
sha256sum /tmp/tar_test_*.tar.gz > /tmp/arbejde.sha256
# Se hvad der er i checksum-filen
cat /tmp/arbejde.sha256
# Output: <lang hash> /tmp/tar_test_2026-03-10_22-50.tar.gz
# Verificer lokalt — bør printe "OK"
sha256sum -c /tmp/arbejde.sha256
# Forventet: /tmp/tar_test_2026-03-10_22-50.tar.gz: OK
```
---
# Del 5 — rsync: Overfør arkiv og checksum til VM2
## Trin 12 — Opret backup-mappe på VM2
```bash
# På VM2
mkdir -p ~/backups/vm1
```
---
## Trin 13 — Overfør begge filer med rsync
Vi overfører nu **to filer**: selve arkivet og dets checksum. Bemærk at vi bruger `vm2` takket være `~/.ssh/config`.
```bash
# På VM1 — overfør arkiv + checksum til VM2
rsync -avh --progress \
/tmp/tar_test_${TIMESTAMP}.tar.gz \
/tmp/arbejde.sha256 \
vm2:~/backups/vm1/
```
> [!info] rsync -z og gzip: dobbelt komprimering?
> rsync's `-z` komprimerer data i **netværkslaget** under overførslen.
> gzip i tar komprimerer **arkivfilens indhold**.
>
> På et lokalt netværk (Host-Only) er forbindelsen hurtig, så rsync's `-z` tilføjer CPU-overhead uden mærkbar gevinst. Vi udelader det her. Over en langsom WAN-forbindelse giver `-z` stadig mening.
---
## Trin 14 — Verificer integritet på VM2
```bash
# På VM2 — verificer at arkivet ikke blev beskadiget under overførslen
cd ~/backups/vm1/
```
Brug nano editor til at ændre stien til filen i `arbejde.sha256`
fx.
```bash
0d048aff42460511ee38fed7b64401c1a94d394e7e93a8db271497e31cc9dfce tar_test_2026-03-10_22-50.tar.gz
```
```bash
sha256sum -c arbejde.sha256
tar_test_2026-03-10_22-50.tar.gz: OK
```
> [!success] "OK" bekræfter
> At arkivfilen på VM2 er bit-for-bit identisk med det der forlod VM1. Dette er det afgørende verifikationstrin — uden det ved du ikke om din backup er brugbar.
---
## Trin 15 — Test komplet restore fra VM2
Simulér en disaster-recovery: slet originaldataene og gendan fra arkivet på VM2.
```bash
# På VM1 — slet arbejdsmappen (simulér datatab)
rm -rf ~/arbejde
ls ~/arbejde
# Forventet: No such file or directory
# Download arkivet fra VM2 (bemærk: vm2 i stedet for brugernavn@IP)
rsync -avh \
vm2:~/backups/vm1/tar_test_*.tar.gz \
~/arbejde/
# Udpak og gendan
tar -xzvf ~/arbejde/tar_test_*.tar.gz -C ~
# Verificer restore
find ~/arbejde -type f
cat ~/arbejde/projekter/alpha.txt
```
> [!tip] Mål din RTO
> Notér: Hvor lang tid tog det fra `rm -rf ~/arbejde` til du kunne læse dine filer igen?
> Det er dit praktiske **RTO** for denne opsætning.
---
# EKSTRA OPGAVE
Som nok skal vente til I har taget hul på faget Automatisering og scripting.
___
# Del 6 — Den tavse fejl: Hvad sker der når VM2 er nede?
Dette er en af de vigtigste lektioner om automatisering. En fejlende cron-job er som udgangspunkt fuldstændig tavs — ingen ved at backup ikke er sket.
## Trin 16 — Simulér nedbrud på VM2
```bash
# På VM2 — stop SSH-serveren
sudo systemctl stop ssh
# På VM1 — forsøg at overføre med rsync
rsync -avh ~/arkiver/arbejde_*.tar.gz vm2:~/backups/vm1/
# Hvad sker der?
# rsync fejler med: "ssh: connect to host 192.168.56.20 port 22: Connection refused"
# Exit-kode er ikke 0
# Start SSH igen på VM2
sudo systemctl start ssh
```
> [!warning] Den tavse cron-fejl
> Hvis dette sker i et automatiseret cron-job, og ingen overvåger logfilen, opdager du fejlen **den dag du har brug for backup-filen** — ikke inden.
>
> Det er præcis den situation der i virkeligheden resulterer i datatab. Scriptet i næste del håndterer dette med exit-kode-tjek og log-alerts.
---
# Del 7 — Automatisering med cron og logrotation
## Trin 17 — Det komplette backup-script
```bash
# På VM1
mkdir -p ~/scripts ~/arkiver ~/logs
nano ~/scripts/backup_til_vm2.sh
```
Indsæt:
```bash
#!/bin/bash
# ================================================================
# backup_til_vm2.sh
# Laver tar-arkiv af ~/arbejde, verificerer med sha256sum
# og overfører til VM2 via rsync. Logger alt til ~/logs/backup.log
# ================================================================
# --- Konfiguration ---
KILDE_MAPPE="$HOME/arbejde"
ARKIV_MAPPE="$HOME/arkiver"
DESTINATION="vm2:~/backups/vm1/" # bruger ~/.ssh/config alias
LOG="$HOME/logs/backup.log"
TIDSSTEMPEL=$(date '+%Y-%m-%d_%H-%M')
DATO_VISNING=$(date '+%Y-%m-%d %H:%M:%S')
ARKIV_NAVN="arbejde_${TIDSSTEMPEL}.tar.gz"
CHECKSUM_NAVN="arbejde_${TIDSSTEMPEL}.sha256"
ARKIV_STI="${ARKIV_MAPPE}/${ARKIV_NAVN}"
CHECKSUM_STI="${ARKIV_MAPPE}/${CHECKSUM_NAVN}"
# --- Forberedelse ---
mkdir -p "$ARKIV_MAPPE" "$HOME/logs"
echo "[$DATO_VISNING] ===== Backup startet =====" >> "$LOG"
# --- Trin 1: Pak med tar (ekskludér tmp og cache) ---
echo "[$DATO_VISNING] Opretter arkiv: $ARKIV_NAVN" >> "$LOG"
tar -czf "$ARKIV_STI" \
--exclude='tmp' \
--exclude='.cache' \
--exclude='*.tmp' \
-C "$HOME" "$(basename $KILDE_MAPPE)" 2>> "$LOG"
TAR_EXIT=$?
if [ $TAR_EXIT -ne 0 ]; then
echo "[$DATO_VISNING] FEJL: tar fejlede (exit $TAR_EXIT)" >> "$LOG"
exit 1
fi
STORRELSE=$(du -sh "$ARKIV_STI" | cut -f1)
echo "[$DATO_VISNING] Arkiv OK: $ARKIV_NAVN ($STORRELSE)" >> "$LOG"
# --- Trin 2: Generer checksum ---
echo "[$DATO_VISNING] Genererer checksum..." >> "$LOG"
sha256sum "$ARKIV_STI" > "$CHECKSUM_STI"
echo "[$DATO_VISNING] Checksum OK: $CHECKSUM_NAVN" >> "$LOG"
# --- Trin 3: Overfør med rsync ---
echo "[$DATO_VISNING] Overfører til VM2..." >> "$LOG"
rsync -avh \
--log-file="$LOG" \
"$ARKIV_STI" "$CHECKSUM_STI" \
"$DESTINATION"
RSYNC_EXIT=$?
if [ $RSYNC_EXIT -ne 0 ]; then
echo "[$DATO_VISNING] FEJL: rsync fejlede (exit $RSYNC_EXIT) — VM2 nede?" >> "$LOG"
exit 2
fi
echo "[$DATO_VISNING] Overførsel OK" >> "$LOG"
# --- Trin 4: Ryd gamle arkiver lokalt (behold seneste 7 dage) ---
find "$ARKIV_MAPPE" -name "arbejde_*.tar.gz" -mtime +7 -delete
find "$ARKIV_MAPPE" -name "arbejde_*.sha256" -mtime +7 -delete
echo "[$DATO_VISNING] Gamle arkiver ryddet (>7 dage)" >> "$LOG"
# --- Trin 5: Logrotation (behold seneste 500 linjer) ---
tail -500 "$LOG" > "${LOG}.tmp" && mv "${LOG}.tmp" "$LOG"
echo "[$DATO_VISNING] ===== Backup fuldført =====" >> "$LOG"
```
```bash
# Gem og luk (Ctrl+X → Y → Enter)
chmod +x ~/scripts/backup_til_vm2.sh
# Test manuelt
~/scripts/backup_til_vm2.sh
# Tjek loggen
cat ~/logs/backup.log
```
---
## Trin 18 — Test den tavse fejl med det nye script
```bash
# Stop SSH på VM2
# (gå til VM2 og kør:)
sudo systemctl stop ssh
# På VM1 — kør scriptet
~/scripts/backup_til_vm2.sh
# Tjek loggen — hvad sker der?
cat ~/logs/backup.log
# Du bør se: "FEJL: rsync fejlede (exit 2) — VM2 nede?"
# Start SSH igen på VM2
sudo systemctl start ssh
# Kør scriptet igen — nu bør det lykkes
~/scripts/backup_til_vm2.sh
cat ~/logs/backup.log
```
> [!success] Forskellen fra før
> Scriptet fejler nu **synligt** i logfilen med en beskrivende besked og en exit-kode der indikerer præcis hvilket trin der fejlede. En overvågningsløsning (fx `logwatch` eller et simpelt mailalert) kan derefter reagere på disse fejlmeldinger automatisk.
---
## Trin 19 — Tilføj til crontab
```bash
crontab -e
# Kør kl. 02:00 hver nat:
0 2 * * * /home/dit-brugernavn/scripts/backup_til_vm2.sh
# Til test — kør hvert 5. minut:
# */5 * * * * /home/dit-brugernavn/scripts/backup_til_vm2.sh
```
> [!tip] Cron-syntaks — hurtigreference
> ```
> ┌──────────── minut (0-59)
> │ ┌────────── time (0-23)
> │ │ ┌──────── dag (1-31)
> │ │ │ ┌────── måned (1-12)
> │ │ │ │ ┌──── ugedag (0-7, 0 og 7 = søndag)
> │ │ │ │ │
> * * * * * kommando
> ```
```bash
# Verificer registrering
crontab -l
# Følg loggen live under test
tail -f ~/logs/backup.log
# Afslut med Ctrl+C
```
> [!warning] Brug altid absolutte stier i crontab
> Cron kører i et minimalt miljø uden din normale `PATH` og `~`-ekspansion.
> Skriv `/home/dit-brugernavn/scripts/...` — aldrig `~/scripts/...`
---
# Del 8 — Refleksion og Fejlsøgning
## Diskussionsspørgsmål
1. Hvad er den præcise forskel på hvad `tar` løser og hvad `rsync` løser? Kan de erstatte hinanden?
2. Scriptet beholder arkiver i 7 dage og logfilen i 500 linjer. Hvad er RPO? Hvad er konsekvensen af at reducere til 3 dage?
3. I målte tid og størrelse for gzip/bzip2/xz. Hvornår ville du vælge bzip2 eller xz frem for gzip i produktion?
4. Hvad sker der, hvis `sha256sum -c` returnerer `FAILED` på VM2? Hvad bør scriptet gøre?
5. Overholder denne opsætning 3-2-1-reglen? Hvad mangler?
6. Sammenlign med rclone-workshoppen — hvad er fordelene ved tar+rsync til lokal server vs. rclone til cloud object storage?
7. Hvem i en rigtig organisation skal modtage besked hvis backup fejler — og hvordan?
---
## Fejlsøgning
| Problem | Sandsynlig årsag | Løsning |
| ------------------------------------- | ---------------------------------- | ----------------------------------------------------- |
| `tar: Cannot open: No such file` | Arkivmappen eksisterer ikke | `mkdir -p ~/arkiver` |
| `tar: Removing leading '/'` | Absolut kildesti brugt | Brug `-C` og relativ sti som i øvelsen |
| `sha256sum -c: FAILED` | Fil beskadiget under overførsel | Overfør igen med rsync og verificer på ny |
| `ssh: Connection refused` | SSH-server kører ikke på VM2 | `sudo systemctl start ssh` på VM2 |
| `Permission denied (publickey)` | Public key ikke kopieret | Kør `ssh-copy-id` igen |
| `ssh: vm2: Name or service not known` | `~/.ssh/config` ikke opsat korrekt | Tjek indrykninger og stavning i config-filen |
| rsync overfører hele filen | `.tar.gz` ændres totalt | Forventet adfærd — brug `--checksum` til verifikation |
| cron-job kører ikke | Relativ sti (`~/`) i crontab | Brug absolutte stier: `/home/bruger/...` |
---
## Best Practices — Checkliste
- [ ] **Tidsstempel i filnavn** — forhindrer at to kørsler samme dag overskriver hinanden
- [ ] **`--exclude` for irrelevante mapper** — `.cache`, `tmp`, `node_modules` giver ikke backup-værdi
- [ ] **Checksum genereres og verificeres** — på VM2 efter overførsel med `sha256sum -c`
- [ ] **Test udpakning lokalt** inden arkivet betragtes som gyldigt (`diff -r`)
- [ ] **Exit-koder tjekkes i scriptet** — tar og rsync fejl logges separat
- [ ] **Logrotation** — logfilen vokser ikke ubegrænset
- [ ] **`~/.ssh/config` opsat** — IP kun defineret ét sted
- [ ] **Den tavse fejl testet** — du ved hvad der sker når VM2 er nede
- [ ] **Absolutte stier i crontab** (`/home/bruger/...` ikke `~/...`)
- [ ] **Restore testet** — komplet disaster-recovery fra VM2 til VM1
---
## Den samlede arbejdsgang
```
VM1 VM2
────────────────────────────────────────── ───────────────────────────────────
~/arbejde/ ~/backups/vm1/
├── projekter/ ├── arbejde_2025-06-08_02-00.tar.gz
├── dokumenter/ tar -czf --exclude ├── arbejde_2025-06-08_02-00.sha256
├── .cache/ ✗──────────────────────► ├── arbejde_2025-06-09_02-00.tar.gz
└── tmp/ ✗ ↓ ├── arbejde_2025-06-09_02-00.sha256
~/arkiver/ ├── arbejde_2025-06-10_02-00.tar.gz
arbejde_DATO_TID.tar.gz └── arbejde_2025-06-10_02-00.sha256
arbejde_DATO_TID.sha256
│
│ rsync -avh
│ (via ~/.ssh/config: vm2)
▼
VM2:~/backups/vm1/
sha256sum -c ← verifikation
```
---