🔴 Advanced

Container Storage — Longhorn, OpenEBS a Rook/Ceph

Kubernetes vás núti konfrontovať s problémom, ktorý bol v klasickom hostingu vyriešený desaťročia — ako uchovať dáta, ktoré prežijú reštart, migráciu a zlyhanie uzla. Kontajnery sú prefíkane stateless, ale databázy, message brokery, repository a filesystem workloads stateful sú. V K8s svete túto medzeru vypĺňajú Container Storage Interface (CSI) drivery, ktoré implementujú PersistentVolume cez distribuované storage systémy.

Tento článok porovnáva tri najpopulárnejšie open-source K8s-natívne storage riešenia — Longhorn, OpenEBS a Rook/Ceph — a pomôže vám vybrať podľa scale, latencie a komplexity.

Problém — prečo PV v K8s nie sú triviálne

Typický Kubernetes cluster beží na viacerých uzloch. Pod spustený na node-3 musí vedieť pristupovať k svojim dátam aj po tom, ako ho scheduler presunie na node-5. Niekoľko spôsobov, ako to riešiť:

1. HostPath (NIKDY v produkcii)

volumes:
- name: data
  hostPath:
    path: /mnt/data

Pripája priečinok z hostiteľského uzla. Problém: ak sa pod presunie, dáta zostanú na pôvodnom uzle. Nepoužívateľné pre HA.

2. Network File System (NFS)

Jednoduchý a fungujúci prístup — NFS server niekde v sieti, všetky uzly mountujú. Problémy:

Single point of failure pri nenaredundovanom NFS.
Pomalá latencia pre transakčné DB (PostgreSQL, MySQL s fsync).
File locking issues pri niektorých aplikáciách (databázy, SQLite).
Security — NFSv3 bez autentifikácie, NFSv4 lepšie ale komplikované.

NFS má miesto pre shared workloady (WordPress uploads, log aggregation pred rotáciou), nie pre primárny DB storage.

3. Cloud provider storage (EBS, GCE PD, Azure Disk)

Ak beží K8s v cloude, natívny storage má CSI driver a funguje. Obmedzenia:

Viaže vás na provider.
AZ lock-in — EBS volume v us-east-1a nemôže byť mountnutý pre pod v us-east-1b.
ReadWriteMany zvyčajne nie — EBS je RWO, musíte použiť EFS (drahé a pomalé).
Cost pri veľkom objeme.

4. Distributed storage (Longhorn, OpenEBS, Rook/Ceph) — náš sweet spot

Replikujú bloky medzi uzlami, poskytujú RWO aj RWX, fungujú on-premise aj v cloude (cez raw disky). Toto je cesta pre serious K8s storage.

Kubernetes storage vrstvy — krátky opakovací materiál

Pred hlbokým ponorom do konkrétnych riešení — rýchlo o K8s abstrakciách:

┌─────────────────────────────────────────────┐
│  Pod                                        │
│  ┌──────────────────────────────────────┐   │
│  │  volumeMounts: /data ← volume name   │   │
│  └───────────────┬──────────────────────┘   │
└──────────────────┼──────────────────────────┘
                   │
             ┌─────▼────────────┐
             │  PVC             │  ← claim
             │  (user-facing)   │
             └─────┬────────────┘
                   │ bind
             ┌─────▼────────────┐
             │  PV              │  ← actual volume
             │  (cluster-level) │
             └─────┬────────────┘
                   │ provisioned by
             ┌─────▼────────────┐
             │  StorageClass    │  ← template
             │  + CSI Driver    │
             └──────────────────┘

PVC (PersistentVolumeClaim) — user's request ("chcem 20 GB, ReadWriteOnce")
PV (PersistentVolume) — konkrétny alokovaný kus storage
StorageClass — "template" pre dynamické provisioning (definuje CSI driver, replikácia, parameters)
CSI driver — plugin, ktorý implementuje konkrétny storage backend

# Príklad StorageClass pre Longhorn
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: longhorn-replica-3
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "30"
  fromBackup: ""

Longhorn — jednoduchý start, robustné jadro

Longhorn je distribuovaný block storage vyvinutý Rancherom (teraz SUSE) a CNCF graduated (2024). Dizajnovaný tak, aby just worked bez hlbokých znalostí storage.

Architektúra Longhorn

┌─────────────────────────────────────────────────────┐
│  Kubernetes Cluster                                 │
│                                                     │
│  ┌─── Node A ──────┐  ┌─── Node B ──────┐  ┌── Node C ──┐
│  │  longhorn-mgr   │  │  longhorn-mgr   │  │ longhorn-mgr│
│  │  ┌──────────┐   │  │  ┌──────────┐   │  │ ┌────────┐ │
│  │  │ engine   │   │  │  │ engine   │   │  │ │ engine │ │
│  │  │ (iSCSI)  │   │  │  │ (iSCSI)  │   │  │ │ (iSCSI)│ │
│  │  │          │◄──┼──┤  │ replica  │◄──┼──┤ replica │ │
│  │  │ replica  │   │  │  │          │   │  │         │ │
│  │  └──────────┘   │  │  └──────────┘   │  │ └────────┘ │
│  │   disk (XFS)    │  │   disk (XFS)    │  │ disk (XFS) │
│  └─────────────────┘  └─────────────────┘  └────────────┘
└─────────────────────────────────────────────────────┘

Každý volume = 1 engine (primary) + N replicas.
Engine beží na uzle, kde je mountnutý pod.
Replicas sú uložené na rôznych uzloch pre HA.

Kľúčové komponenty:

Longhorn Manager — DaemonSet na každom uzle, spravuje volumes
Longhorn Engine — per-volume proces (iSCSI target), hovorí s replicas cez TCP
Longhorn UI — web dashboard na porte 80 (typicky cez Ingress)

Inštalácia

helm repo add longhorn https://charts.longhorn.io
helm repo update

helm install longhorn longhorn/longhorn \
  --namespace longhorn-system \
  --create-namespace \
  --version 1.7.2 \
  --set defaultSettings.defaultReplicaCount=3 \
  --set defaultSettings.defaultDataPath="/var/lib/longhorn" \
  --set persistence.defaultClass=true \
  --set persistence.defaultClassReplicaCount=3

# Overte, že sú uzly ready pre Longhorn
kubectl get nodes.longhorn.io -n longhorn-system

Predpoklady na uzloch:

iscsiadm (open-iscsi package) — Longhorn používa iSCSI pre engine↔replica komunikáciu
nfs-common (pre ReadWriteMany cez internal NFS)
jq, curl, nsenter
Kernel modul iscsi_tcp načítaný

# Debian/Ubuntu
sudo apt install open-iscsi nfs-common
sudo systemctl enable iscsid && sudo systemctl start iscsid

# RHEL/Rocky
sudo dnf install iscsi-initiator-utils nfs-utils

Kľúčové vlastnosti

Synchronous replication — write return až po potvrdení od všetkých replicas
Distributed block store — nie je potreba dedikovaný storage pool, používa lokálne disky
Incremental snapshots — úložiskové snímky, backup do S3
Cross-cluster DR — replikácia volumes medzi klastermi
ReadWriteMany cez NFS sidecar (pomalšie než RWO)
Encrypted volumes (dm-crypt)
V2 Data Engine — experimentálny SPDK backend pre rýchlejšie IOPS

Backup do S3

# Longhorn BackupTarget
apiVersion: longhorn.io/v1beta2
kind: BackupTarget
metadata:
  name: default
  namespace: longhorn-system
spec:
  backupTargetURL: "s3://longhorn-backups@us-east-1/"
  credentialSecret: s3-secret
  pollInterval: "5m"

# Recurring backup každých 6 hodín, ponechať 24 záloh
apiVersion: longhorn.io/v1beta2
kind: RecurringJob
metadata:
  name: backup-6h
  namespace: longhorn-system
spec:
  cron: "0 */6 * * *"
  task: "backup"
  retain: 24
  groups:
    - "production"

Kedy Longhorn

Stredne veľké klastre (5–50 uzlov, <100 TB).
Tím nemá storage špecialistu.
Potrebujete rýchlo začať (1 hodina od nuly).
Edge / on-premise prostredia.

Keď Longhorn nie

Scale nad 100 TB — Longhorn UI začne byť pomalý, je to architektural limit.
Potrebujete object storage aj block storage v jednom — tam Ceph.
Musíte mať sub-ms latenciu — iSCSI overhead nie je zanedbateľný.

OpenEBS — modulárna architektúra, viacero engines

OpenEBS od MayaData (teraz DataCore) je CNCF sandbox projekt, ktorý poskytuje viacero storage engines pod jedným API. Filozofia: vyberte si engine podľa use-case.

Dostupné engines

Engine	Typ	Vhodné pre
Mayastor	NVMe-oF, SPDK-based	High-performance, low latency (<1ms p99)
cStor	iSCSI, ZFS-backed	Feature-rich (snapshots, clones, thin provisioning)
Jiva	Legacy, pure userspace	Small clusters, development
LVM LocalPV	LVM2 na node	Single-node workloads, databáza na nodom
ZFS LocalPV	ZFS na node	Local storage s snapshot/clone funkcionalitou
Hostpath LocalPV	Bare hostPath + CSI	Replace ručných hostPath mounts

V 2026 je odporúčaný engine Mayastor pre performance-sensitive workloads a LVM LocalPV / ZFS LocalPV pre dátové workloady, kde chcete využiť lokálne disky (napr. Kafka, databázy s vlastnou replikáciou).

Mayastor — moderný NVMe-oF engine

Mayastor používa SPDK (Storage Performance Development Kit) a NVMe-over-Fabrics (TCP) namiesto iSCSI. Výsledok: latencia porovnateľná s lokálnym NVMe diskom.

┌────────────────────────────────────────────┐
│  Kubernetes                                │
│                                            │
│  ┌─ Node A ──────┐  ┌─ Node B ──────┐  │
│  │  mayastor-io  │  │  mayastor-io  │  │
│  │  ┌──────────┐ │  │  ┌──────────┐ │  │
│  │  │  NVMe-oF │ │  │  │  NVMe-oF │ │  │
│  │  │  target  │◄├──┼──┤  replica │ │  │
│  │  └──────────┘ │  │  └──────────┘ │  │
│  │  NVMe disk    │  │  NVMe disk    │  │
│  └───────────────┘  └───────────────┘  │
│                                            │
│  Control plane: mayastor-csi, etcd         │
└────────────────────────────────────────────┘

Inštalácia:

kubectl create ns mayastor
kubectl label node nvme-node1 openebs.io/engine=mayastor
kubectl label node nvme-node2 openebs.io/engine=mayastor
kubectl label node nvme-node3 openebs.io/engine=mayastor

# HugePages configuration (required for SPDK)
# 1024 (2 GB) je minimum pre dev, 2048 (4 GB) odporúčané pre produkciu s NVMe-oF
echo vm.nr_hugepages=2048 | sudo tee -a /etc/sysctl.conf
sudo sysctl -p

helm repo add openebs https://openebs.github.io/openebs
helm install openebs openebs/openebs \
  --namespace openebs \
  --create-namespace \
  --set engines.replicated.mayastor.enabled=true

# DiskPool — povie Mayastoru, ktorý NVMe disk má použiť
apiVersion: openebs.io/v1beta2
kind: DiskPool
metadata:
  name: pool-node1
  namespace: openebs
spec:
  node: nvme-node1
  disks:
    - /dev/nvme0n1

# StorageClass pre Mayastor s 3 replikami
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: mayastor-3replica
provisioner: io.openebs.csi-mayastor
allowVolumeExpansion: true
parameters:
  repl: "3"
  protocol: nvmf
  ioTimeout: "30"
  fsType: xfs

LVM LocalPV — pre workloady s vlastnou replikáciou

Niektoré workloady (Kafka, Cassandra, PostgreSQL Patroni, CockroachDB) si replikáciu riešia samé na aplikačnej vrstve. V tom prípade synchronous replikácia na storage vrstve len znásobuje write amplification. LocalPV dáva vašim podom rýchly lokálny disk cez CSI:

helm install openebs openebs/openebs \
  --namespace openebs \
  --create-namespace \
  --set engines.local.lvm.enabled=true

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-lvm
provisioner: local.csi.openebs.io
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
  storage: "lvm"
  volgroup: "vg-data"
  fsType: "ext4"

Volume sa alokuje z LVM volume group na konkrétnom uzle. WaitForFirstConsumer zabezpečí, že scheduler naplánuje pod na uzol, kde je dostatok miesta.

Kedy OpenEBS

Máte mix workloadov, každý s inými požiadavkami (DB chce rýchlosť, log storage objem).
Máte NVMe disky a chcete ich využiť naplno (Mayastor).
Beží vám Kafka/Cassandra/CockroachDB — LocalPV + ich replikácia je efektívne.

Keď OpenEBS nie

Malý tím, jedna aplikácia — komplexita engines je overkill (Longhorn stačí).
Potrebujete object storage (S3 API) — OpenEBS to nemá.

Rook/Ceph — enterprise-grade distributed storage

Ceph je veterán distribuovaného storage (prvý release 2006). Rook je Kubernetes operator, ktorý Ceph "baluje" do K8s-natívnej skúsenosti (CRD-based config, CSI driver). CNCF graduated (2020).

Ceph poskytuje tri typy storage naraz z rovnakého pool-u:

RBD (RADOS Block Device) — block storage pre VMs a DB
CephFS — distribuovaný POSIX filesystem (RWX)
RGW (RADOS Gateway) — S3-kompatibilné object storage

Architektúra

┌────────────────────────────────────────────────────────┐
│  Rook Operator (CRD-based control plane)               │
│  ┌──────────────┐ ┌──────────────┐ ┌────────────────┐  │
│  │  CephCluster │ │  CephBlockPool│ │ CephObjectStore│  │
│  └──────────────┘ └──────────────┘ └────────────────┘  │
└──────────────────────────┬─────────────────────────────┘
                           │ provisions
                ┌──────────▼──────────┐
                │  Ceph Cluster        │
                │  ┌─────────────────┐ │
                │  │  MON daemons    │ │  Consensus (etcd-like)
                │  │  (3× odporúčané)│ │
                │  └─────────────────┘ │
                │  ┌─────────────────┐ │
                │  │  MGR daemon     │ │  Management (dashboard, metrics)
                │  └─────────────────┘ │
                │  ┌─────────────────┐ │
                │  │  OSD daemons    │ │  Object storage (per disk)
                │  │  (N× = N×disks) │ │
                │  └─────────────────┘ │
                │  ┌─────────────────┐ │
                │  │  MDS daemons    │ │  Metadata (pre CephFS)
                │  └─────────────────┘ │
                │  ┌─────────────────┐ │
                │  │  RGW daemons    │ │  S3 gateway
                │  └─────────────────┘ │
                └──────────────────────┘

Inštalácia

helm repo add rook-release https://charts.rook.io/release
helm install rook-ceph rook-release/rook-ceph \
  --namespace rook-ceph \
  --create-namespace

# CephCluster CR
apiVersion: ceph.rook.io/v1
kind: CephCluster
metadata:
  name: rook-ceph
  namespace: rook-ceph
spec:
  cephVersion:
    image: quay.io/ceph/ceph:v19.2.0  # Squid (aktuálny stable v 2026); v18.2.x (Reef) už len v maintenance
  dataDirHostPath: /var/lib/rook
  mon:
    count: 3
    allowMultiplePerNode: false
  mgr:
    count: 2
    modules:
      - name: prometheus
        enabled: true
      - name: dashboard
        enabled: true
  dashboard:
    enabled: true
    ssl: true
  storage:
    useAllNodes: true
    useAllDevices: false
    deviceFilter: "^nvme"
    config:
      osdsPerDevice: "1"
      storeType: "bluestore"

# Block pool (RBD) + StorageClass
apiVersion: ceph.rook.io/v1
kind: CephBlockPool
metadata:
  name: replicapool
  namespace: rook-ceph
spec:
  failureDomain: host
  replicated:
    size: 3
    requireSafeReplicaSize: true
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: rook-ceph-block
provisioner: rook-ceph.rbd.csi.ceph.com
allowVolumeExpansion: true
reclaimPolicy: Delete
parameters:
  clusterID: rook-ceph
  pool: replicapool
  imageFormat: "2"
  imageFeatures: layering
  csi.storage.k8s.io/fstype: xfs

Kľúčové vlastnosti

Production-proven — používa to CERN, Red Hat, SAP, tisícky firiem. Petabyte-scale.
Block + file + object v jednom systéme.
Erasure coding — alternatíva k replikácii, šetrí miesto (4+2 EC = 50% overhead vs 3× replica = 200%).
Placement groups & CRUSH algorithm — automatický rebalance pri výpadku uzla.
Snapshots, clones, thin provisioning, encryption-at-rest.
Dashboard — pokročilý Ceph dashboard s metrikami.

Keď Rook/Ceph

Veľký klaster (10+ uzlov).
Potrebujete block + file + object storage v jednom.
Máte operátora, ktorý sa vie postarať o Ceph (nie je to plug-and-forget).
Petabyte scale, multi-site (Ceph dokáže cross-site replikáciu).

Keď Rook/Ceph nie

Malý klaster (<5 uzlov) — overhead MON/MGR/OSD daemons je neúmerný.
Tím nemá storage-oriented ops.
Chcete rýchly start bez learning curve.

Porovnanie — Longhorn vs OpenEBS vs Rook/Ceph

Kritérium	Longhorn	OpenEBS Mayastor	Rook/Ceph
Learning curve	✅ Nízka	⚠️ Stredná	❌ Strmá
Min cluster size	3 uzly	3 uzly	4+ uzly (3× MON)
Max scale	~100 TB	~PB (s dostatočnými nodes)	✅ Multi-PB
Block storage (RBD)	✅	✅	✅
File (RWX)	⚠️ Cez NFS sidecar	❌ (len LocalPV)	✅ CephFS
Object storage (S3)	❌	❌	✅ RGW
Latency (NVMe)	⚠️ iSCSI overhead	✅ NVMe-oF	⚠️ Stredná
Snapshots	✅	✅ (cStor, ZFS)	✅
Encryption	✅ dm-crypt	✅	✅
Multi-AZ/DC	⚠️ Len DR replikácia	❌	✅ Cross-site
UI	✅ Integrovaný	⚠️ Kubectl	✅ Ceph dashboard
CNCF	Graduated (2024)	Sandbox	Graduated (2020)
Community	✅ Rancher/SUSE	⚠️ Menšia	✅ Veľká
Disk space overhead	2–3× (replikácia)	2–3× alebo EC	3× alebo EC 1.5×

Rozhodovací strom

Začíname s K8s storage? 
│
├─ Máme <5 uzlov? ──YES──► Longhorn
│        │
│        NO
│        ▼
├─ Potrebujeme object storage (S3) z toho istého clusteru? ──YES──► Rook/Ceph
│        │
│        NO
│        ▼
├─ Máme NVMe disky + workloady citlivé na latenciu (OLTP DB)? ──YES──► OpenEBS Mayastor
│        │
│        NO
│        ▼
├─ Beží nám Kafka/Cassandra/CockroachDB s vlastnou replikáciou? ──YES──► OpenEBS LocalPV
│        │
│        NO
│        ▼
├─ Máme storage-oriented ops tím a >10 uzlov? ──YES──► Rook/Ceph
│        │
│        NO
│        ▼
└─ Default: Longhorn

Prevádzkové aspekty — čo naozaj bolí

1. Backup stratégia

Žiadne z týchto riešení nie je backup. Replikácia chráni proti hardware failure, nie proti chybnému DELETE FROM users. Vždy kombinujte so samostatným backup systémom:

Velero — K8s-native backup s CSI snapshot integráciou.
Stash — AppsCode's backup nástroj.
Kasten K10 — komerčný, pokročilé features.

Viac v samostatnom článku o Velero.

2. Monitoring

Všetky tri exportujú Prometheus metriky:

Longhorn — longhorn_volume_actual_size_bytes, longhorn_node_status, longhorn_disk_capacity_*.
OpenEBS Mayastor — mayastor_io_read_ops_total, mayastor_io_write_latency_seconds.
Ceph — veľmi bohaté, cez ceph-mgr prometheus module. Existuje oficiálny Grafana dashboard.

Kľúčové alerty:

Replika volume v Degraded stave
Disk utilization > 80% (pred nearfull warningom, máte čas reagovať)
OSD/Engine/Replica down
Slow requests (Ceph)

3. Upgrade

Tu je Longhorn najpríjemnejší (rolling upgrade daemonsetu), Ceph najkomplexnejší (MON quorum, OSD upgrade order, MDS prednosti). Vždy si:

Prečítajte upgrade notes konkrétnej verzie.
Otestujte v staging.
Majte backup hneď pred upgradom.

4. Disaster recovery

Longhorn — BackupTarget + RecurringJob do S3. Restore: nový klaster → Volume s fromBackup: <path>.
OpenEBS Mayastor — použiť Velero s CSI snapshot.
Ceph — rbd mirror pre cross-site replikáciu, alebo snapshot → import do iného clusteru.

Anti-patterns a časté chyby

Používať 2 replicas — 2-replica setup znamená, že pri výpadku jednej repliky máte 50% šancu straty dát (žiadna fault tolerance) a cluster ide do degraded stavu hneď. Vždy 3 pre prežitie jedného výpadku (alebo 5 pre dva súčasné). (Terminológia "quorum" platí pre control plane ako Ceph MONs, nie priamo pre volume replicas — tam ide o fault tolerance.)
Nedávať failure domain — ak všetky repliky skončia na jednom rack-u (failureDomain neconfigured), strácate HA. V Rook použite failureDomain: rack + CRUSH map.
Spoločný pool pre rýchle + pomalé workloady — v Ceph rozdeľte na NVMe pool a HDD pool s rôznymi StorageClass. V OpenEBS si vybrať iný engine.
Monitoring zapnúť "neskôr" — neskôr budete hľadať dáta na chybu z pred mesiaca a nenájdete ich. Zapnite Prometheus hneď.
Nikdy netestovať restore — "máme backup" nie je to isté ako "vieme z backupu obnoviť". Rovnako ako pri Velero — chaos DR test aspoň raz za kvartál.
Ignorovať hugepages — Mayastor ich vyžaduje (vm.nr_hugepages). Bez nich beží degradovane.
Ukladať MON state na nestabilný storage — Ceph MON quorum je kritická. Použite dataDirHostPath na každom MON uzle a monitorujte disk.

Zhrnutie

Voľba container storage v K8s je dlhodobé rozhodnutie — migrácia medzi systémami znamená drain, re-provision a application downtime. Preto:

Začnite s Longhornom, ak ste v pochybnostiach a máte malý/stredný klaster. Prejdete na 80% situácií.
OpenEBS Mayastor, ak potrebujete vysoký IOPS (databázy, message brokers) a máte NVMe disks.
OpenEBS LocalPV, ak aplikácia už replikuje sama.
Rook/Ceph, ak je K8s pre vás dlhodobá platforma, máte viac ako 10 uzlov a potrebujete multi-protocol storage.

Bez ohľadu na voľbu, backup stratégia je nezávislá vrstva. Replikácia ≠ backup. Velero + S3 offsite backupy sú štandard.

Container Storage — Longhorn, OpenEBS a Rook/Ceph

Problém — prečo PV v K8s nie sú triviálne

1. HostPath (NIKDY v produkcii)

2. Network File System (NFS)

3. Cloud provider storage (EBS, GCE PD, Azure Disk)

4. Distributed storage (Longhorn, OpenEBS, Rook/Ceph) — náš sweet spot

Kubernetes storage vrstvy — krátky opakovací materiál

Longhorn — jednoduchý start, robustné jadro

Architektúra Longhorn

Inštalácia

Kľúčové vlastnosti

Backup do S3

Kedy Longhorn

Keď Longhorn nie

OpenEBS — modulárna architektúra, viacero engines

Dostupné engines

Mayastor — moderný NVMe-oF engine

LVM LocalPV — pre workloady s vlastnou replikáciou

Kedy OpenEBS

Keď OpenEBS nie

Rook/Ceph — enterprise-grade distributed storage

Architektúra

Inštalácia

Kľúčové vlastnosti

Keď Rook/Ceph

Keď Rook/Ceph nie

Porovnanie — Longhorn vs OpenEBS vs Rook/Ceph

Rozhodovací strom

Prevádzkové aspekty — čo naozaj bolí

1. Backup stratégia

2. Monitoring

3. Upgrade

4. Disaster recovery

Anti-patterns a časté chyby

Zhrnutie

Ďalšie čítanie