DFU 06, Replication & Backup

# DFU 06
## Replication & Backup

---

## Disaster Recovery Strategier

----

### Hvad er Disaster Recovery (DR)?

- DR er **planen for at genskabe systemer, data og drift** efter en hændelse (e.g. katastrofe, cyberangreb, hardwarefejl)

- En del af virksomhedens **Business Continuity Plan (BCP)**

- Fokus: *hvordan kommer vi tilbage online?*

----

#### Disaster Recovery vs Backup

----

### Typiske Scenarier for DR

- Naturkatastrofer (f.eks. oversvømmelser, jordskælv)

- Cyberangreb (f.eks. ransomware)

- Hardwarefejl (f.eks. diskfejl, servernedbrud)

- Menneskelige fejl (f.eks. utilsigtet sletning af data)

- Softwarefejl (f.eks. datakorruption)

- Strømfejl eller netværksnedbrud

- Infrastrukturfejl (f.eks. datacenter nedbrud)

- Leverandørfejl (f.eks. cloud-udbyder nedbrud)

- Sikkerhedsbrud (f.eks. datalækage)

----

### Risikovurdering

- **Identificér kritiske systemer**
    - Hvad er nødvendigt for forretningen?
    - Hvilke systemer kan ikke undværes?

</div>
<div class="fragment">

- Kritiske systemer:
    - F.eks. ERP, CRM, e-mail, databaser, webservere
    - Hvilke data er mest værdifulde?
    - F.eks. kundedata, finansdata, intellektuel ejendom

</div>
</div>

----

### Risikovurdering (fortsat)

- **Vurder trusler og sansynlighed**
    - Hvilke trusler er mest relevante?
    - Hvor sandsynligt er det, at de opstår?

</div>
<div class="fragment">

- Relevante trusler:
    - Naturkatastrofer, cyberangreb, hardwarefejl, menneskelige fejl
    - Vurder konsekvenserne af hver trussel

</div>
</div>

----

### Risikovurdering (fortsat)

- **Vurder konsekvens (impact)**
    - Hvad er konsekvenserne for forretningen?
    - F.eks. økonomiske tab, omdømmetab, juridiske konsekvenser

</div>
<div class="fragment">

- Konsekvensvurdering:
    - Høj, medium, lav
    - Prioriter risici baseret på sansynlighed og konsekvens
    - Typisk værktøj, f.eks. risikomatrix

</div>
</div>

----

### Risikovurdering (fortsat)

- **Prioritér gendannelse**
    - Hvilke systemer skal gendannes først?
    - F.eks. kritiske systemer, der understøtter forretningen

</div>
<div class="fragment">

- Gendannelsesprioritering:
    - F.eks. ERP før interne systemer
    - Dokumentér prioriteringer i DR-planen

</div>
</div>

----

### Riskomatrix

- En riskomatrix hjælper med at visualisere og prioritere risici baseret på sansynlighed og konsekvens

- Typisk opdelt i kategorier som høj, medium og lav

Eksempel:

| System | Kritikalitet | Sansynlighed | Konsekvens | Prioritet |
| :----- | :----------- | :----------- | :--------- | :-------- |
| Database | Høj          | Lav          | Høj        | 1         |
| ERP    | Høj          | Medium       | Høj        | 1         |
| CRM    | Medium       | Lav          | Medium     | 3         |
| E-mail | Høj          | Høj          | Høj        | 2         |

</div>

----

### RTO & RPO

- **RTO (Recovery Time Objective)**: Maksimal tolerabel nedetid for et system
- **RPO (Recovery Point Objective)**: Maksimal tolerabel datatab i tid (bagud)

Eksempel:

- RPO = 15 minutter
- RTO = 1 time<br>
    -> Backup og failover skal understøtte disse mål
- Skal typisk identificeres i SLO'er og dermed i SLA'er

</div>

----

### DR Strategier i praksis

1. **warm standby**, hvor en minimal infrastruktur er klar til at tage over med kort varsel, e.g. en standby server med replikering af databasen
2. **hot standby**, hvor en fuld infrastruktur er klar til at tage over med minimal nedetid, e.g. en aktiv-passiv cluster setup

</div>

----

### Disaster Recovery Plan (DRP)

- En **DR-Plan** skal indeholde:
    - Kontakpersoner og roller, inkl. ansvarlige for gendannelse
    
    - Systemprioritet og afhængigheder
    
    - Backup- og restoreprocedurer
    
    - Failoverstrategi og testplan
    
    - Kommunikationsplan (intern/ekstern)

----

### Kommunikation under kriser

- Interne roller:
    - DR-leder
    - IT-ansvarlig
    - kommunikationsansvarlig
- Eksterne interessenter:
    - Kunder, Leverandører, Myndigheder
- Formål:
    - undgå panik og misinformation
    - sikre alle er informeret
    - sikre interne og eksterne kommunikationskanaler er åbne

----

## DR og Cloud

- Brug af multi-region og multi-availability zone arkitektur

- Cloud-tjenester tilbyder ofte:

    - Indbyggede backup-løsninger
    
    - Replikering på tværs af regioner
    
    - Automatiserede failover-mekanismer
    
- Men ansvaret for plan og test ligger stadig hos virksomheden

----

### Automatisering og orkestrering

- DR kan automatiseres med f.eks.:

    - Terraform (Infrastructure as Code)
    
    - Ansible (konfigurationsstyring)
    
    - CI/CD pipelines (automatiseret test og deployment)

----

### Øvelse

I improviserede grupper (3 personer):

30 minutter, med præsentation på 5 minutter

1. Vælg et kritisk system
2. Definér RTO og RPO
3. Beskriv en DR-strategi (backup, failover, failback)
4. Lav en kort Kommunikationsplan
5. Diskutér hvordan I vil teste planen

---

## Backup

----

### Hvorfor Backup?

- Backup beskytter mod:
    - Hardwarefejl (disk, memory, PSU etc.)
    
    - Softwarefejl og datakorruption
    
    - Ransomware og utilsigtet sletning
    
    - Naturkatastrofer og menneskelige fejl

- Backup handler ikke kun om **at have en kopi**, men om **at kunne genskabe driften**<br>
    -> en del af *Disaster Recovery* strategien

----

### Typer af backup

----

### Fuld backup

- En fuld backup kopierer alle data i systemet

- Fordele:

    - Simpel at forstå og gendanne fra
    
    - Alle data er samlet i én backup
    
- Ulemper:

    - Tager længst tid at lave
    
    - Kræver mest lagerplads

----

### Differential Backup

- En differential backup kopierer alle ændringer siden sidste fulde backup

- Fordele:

    - Hurtigere end fuld backup
    
    - Mindre lagerplads end fuld backup
    
- Ulemper:

    - Restore kræver både fuld backup og seneste differential backup
    
    - Kan vokse hurtigt i størrelse over tid

----

### Incremental Backup

- En incremental backup kopierer kun ændringer siden sidste backup (uanset type)

- Fordele:

    - Mindst lagerplads og hurtigst at lave
    
- Ulemper:

    - Restore kræver fuld backup + alle efterfølgende incremental backups
    
    - Mere kompleks at administrere

----

### Logical vs. Physical Backup

- Logical Backuper, er typisk database dumps (f.eks. SQL dump)

    - Fordele: Platformuafhængig, let at læse og redigere
    
    - Ulemper: Kan være langsommere at gendanne, større filer
    
    - Bruges ofte til mindre databaser eller specifikke tabeller

- Physical Backuper, er kopier af de fysiske datafiler

    - Fordele: Hurtigere gendannelse, nøjagtig kopi af data
    
    - Ulemper: Platformafhængig, kan være sværere at administrere
    
    - Bruges ofte til store databaser eller hele systemer

----

### Hot vs Cold Backup

- Hot Backup (Online Backup):
    - Tager backup mens systemet er i drift
    - Fordele: Ingen nedetid, kontinuerlig beskyttelse
    - Ulemper: Kan påvirke ydeevne, kompleksitet
- Cold Backup (Offline Backup):
    - Tager backup mens systemet er nede
    - Fordele: Simpel, ingen risiko for dataintegritet
    - Ulemper: Kræver nedetid, ikke egnet til kritiske systemer
- "Warm" backup er en mellemting, hvor systemet er delvist tilgængeligt
    - F.eks, read-only tilstand under backup

----

### Backup Lokationer

- On-site backup:
    - Hurtig adgang og gendannelse
    - Risiko ved lokal katastrofe

- Off-site backup:
    - Beskyttelse mod lokal katastrofe
    - Længere gendannelsestid

----

### 3-2-1 Backup Reglen

- **3 Kopier** af dine data

- **2 Forskellige medier** (f.eks. disk og tape)

- **1 Off-site kopi** (f.eks. cloud eller ekstern lokation)

----

### Retention og rotation

Eksempel på rotationsstrategi:

- Daglig: behold 7 dages backup

- Ugentlig: behold 4 ugers backup

- Månedlig: behold 12 måneders backup

- Husk lovkrav og data-compliance (GDPR, HIPAA etc.)

----

### Backup Automatisering

- Brug scripts og værktøjer til at automatisere backup-processen

- Planlæg regelmæssige backups (f.eks. cron jobs)

- Overvåg backup-status og alarmer ved fejl

- Test regelmæssigt gendannelse fra backup, så du ikke har "Schrödingers backup"

----

### Automatiseringsmetoder

- Cron jobs (Linux/Unix)

- Windows Task Scheduler

- Backup-software med indbygget planlægning (f.eks. Veeam, Bacula)

- Cloud-tjenester med automatiserede backup-muligheder (f.eks. AWS Backup, Azure Backup)

---

## Backup Værktøjer

----

### PostgreSQL Backup Værktøjer

- **WAL (Write-Ahead Logging)**:
    - Sikrer dataintegritet ved at logge ændringer før de skrives til databasen
    - Muliggør point-in-time recovery ved at anvende WAL-filer efter en restore
    - [https://www.postgresql.org/docs/current/continuous-archiving.html](https://www.postgresql.org/docs/current/continuous-archiving.html)

----

### pg_dump Eksempel

Eksempel på fuld backup af en database:

```bash []
pg_dump -U myuser -F c -b -v -f /path/to/backup/mydb.backup mydb
```

Eksempel på restore fra en backup:

```bash []
pg_restore -U myuser -d mydb -v /path/to/backup/mydb.backup
```

----

### pg_basebackup Eksempel

Eksempel på fysisk backup af en database:

```bash []
pg_basebackup -D /path/to/backup -F tar -z -P -U replication_user
```

Eksempel på gendannelse:

```bash []
tar -xvf /path/to/backup/base.tar.gz -C /var/lib/postgresql/data
```

----

### Microsoft SQL Server Backup Værktøjer

----

### SQL Server Management Studio (SSMS)

- Grafisk interface til at administrere SQL Server
- Se link for guide [https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/create-a-full-database-backup-sql-server?view=sql-server-ver17](https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/create-a-full-database-backup-sql-server?view=sql-server-ver17)

----

### T-SQL Commands

Eksempel på fuld backup:

```sql []
BACKUP DATABASE [MyDatabase] TO DISK = N'C:\Backups\MyDatabase.bak' WITH NOFORMAT, NOINIT, NAME = N'MyDatabase-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, STATS = 10
```

Eksempel på restore

```sql []
RESTORE DATABASE [MyDatabase] FROM DISK = N'C:\Backups\MyDatabase.bak' WITH FILE = 1, NOUNLOAD, REPLACE, STATS = 10
```

----

### MySQL / MariaDB Backup Værktøjer

----

### mysqldump Eksempel

Eksempel på fuld backup af en database:

```bash []
mysqldump -u myuser -p mydb > /path/to/backup/mydb.SQL
```

Eksempel på restore fra en backup:

```bash []
mysql -u myuser -p mydb < /path/to/backup/mydb.SQL
```

----

### Percona XtraBackup Eksempel

Eksempel på fysisk backup af en database:

```bash []
xtrabackup --backup --target-dir=/path/to/backup --user=myuser --password=mypassword
```

Eksempel på gendannelse:

```bash []
xtrabackup --prepare --target-dir=/path/to/Backup
xtrabackup --copy-back --target-dir=/path/to/Backup
```

---

## Database Replication

----

### Hvad er Replication?

- **Replication** betyder at **kopiere data fra én database (source)** til **en eller flere andre database (replicas)**

- Formål:

    - Høj tilgængelighed (HA)
    
    - Load balancing
    
    - Disaster recovery
    
    - Geografisk distribution

----

### Hvorfor Replication?

- Hurtigere læsning

- Højere oppetid (redundans)

- Geografisk distribution

- Backup af aktiv database (hot backup)

- Disaster Recovery i realtid

----

### Replication er ikke backup

- Backup = genskabelse af historisk data

- Replication = kopiering af aktuel data

- Hvis du sletter data på source, slettes det også på replica(s)

- Backup og replication supplerer hinanden, men erstatter ikke hinanden

----

### Grundlæggende begreber

----

### Replication Typer

----

![Replication Types](/assets/db-replication-async-sync.png)

----

### Asynkron Replication

- Fordele:
    - Hurtig - minimal latency
    - Skalerer godt med mange replicas

- Ulemper:
    - Risiko for datatab, hvis source fejler før replica opdateres
    - Ikke garanteret konsistens mellem source og replicas

- Brugsscenarier
    - Læs-skalering
    - Geografisk distribution
    - Disaster recovery med acceptabelt datatab

----

### Semisynkron Replication

- Fordele:
    - Mindre risiko for datatab hvis source fejler før replica opdateres
    - God balance mellem hastighed og sikkerhed

- Ulemper:
    - Ikke garanteres konsistens mellem source og flere replicas
    - Kan introducere noget latency, afhængig af netværksforhold

- Brugsscenarier:
    - Kritiske applikationer hvor datatab skal minimeres
    - Systemer med få replicas

----

### Synkron Replication

- Fordele:
    - Nærmest garanteret ingen datatab ved nedbrud
    - Ekstrem høj datasikkerhed

- Ulemper:
    - Langsom - source **skal** vente på alle replicas
    - Kræver hurtigere forbindelse og synkron clock mellem noder

- Brugsscenarier:
    - Ekstremt kritiske systemer (f.eks. finansielle transaktioner)
    - Systemer med få noder i tæt geografisk område

----

### Replication Topologier

- Source/Replica
    - En source, flere replicas
    - Passer til de fleste Scenarier
    - Der findes flere varianter af Source/replica
        - e.g. Chain replication
- Source/Source
    - Flere sources
    - Bruges til dataintegration og geografisk distribution
    - Mere kompleks at administrere

----

### Source/Replica

- En enkelt source database der håndterer alle skriveoperationer (DML, DDL m.v.)

- En eller flere replica databaser der håndterer læseoperationer (DQL)

- Typisk asynkron eller semisynkron Replication

----

### Source/Replica

Regular setup

![Source Replica](/assets/db-replication-source-replica.svg)

----

### Eksempel med loadbalancer

- Load balancing på ...
    - porte e.g. (write: 5432, read: 5433)
    - IP'er e.g. (write: 10.0.0.5, read: 10.0.0.6)
    - DNS e.g. (write: db-write.example.com, read: db-read.example.com)

</div>

----

### Source/Source replication

- Flere kilder der hver håndterer skriveoperationer

- Hver source kan have egne replicas

- Bruges til dataintegration og geografisk distribution

- Mere kompleks at administrere

----

### Source/Source replication m. LB

![db-replication-source-source.svg](/assets/db-replication-source-source.svg)

</div>
<div>

- Load balancing peger
    - Samme port til alle instancer
    - Samme IP til alle instancer
    - Samme DNS til alle instancer

</div>
</div>

----

### Konflikthåndtering

- I Source/Source replication kan der opstå konflikter ved samtidige writes

- Konflikthåndtering kan ske på flere måder:

    - Last write wins (LWW)
    
    - Versionering
    
    - Applikationslogik

- Dette er for komplekst til at dække

---

## Replication i praksis

[https://github.com/ucldk/mysql-replication-example](https://github.com/ucldk/mysql-replication-example)

bash

sql

bash