2.4 KiB
2.4 KiB
🗂️ Stratégie de stockage & sauvegarde
Pools ZFS
| Pool | Disques | Usage | Redondance |
|---|---|---|---|
boot-pool |
1× NVMe 256 Go | Système TrueNAS Scale | Aucune (réinstallable) |
apps-pool |
2× SSD 500 Go | Applications, bases Docker | Miroir |
data-pool |
2× HDD 4 To | Photos, vidéos, documents | Miroir |
media-pool |
1× HDD 8 To | Bibliothèque multimédia (Jellyfin) | Aucune (non critique) |
Snapshots
- Fréquence : quotidienne sur
data-pool, hebdomadaire surapps-pool. - Politique de rétention : conservation glissante (ex. 7 jours / 4 semaines / 6 mois) à adapter selon l'espace disponible.
- Objectif : pouvoir revenir en arrière en cas de suppression accidentelle ou de chiffrement par un ransomware, sans dépendre uniquement de la sauvegarde distante.
Stratégie 3-2-1 (adaptée à un usage personnel)
3 copies des données
│
┌──────────┼──────────────┐
│ │ │
Original Snapshot ZFS Sauvegarde
(data-pool) (local) cloud chiffrée
(pCloud, 2 To)
- Copie 1 — données originales sur
data-pool(miroir ZFS). - Copie 2 — snapshots ZFS locaux (protection contre erreur humaine / ransomware récent).
- Copie 3 — synchronisation chiffrée vers pCloud (2 To, abonnement à vie), hors-site, pour couvrir un sinistre matériel ou un vol.
Les sauvegardes distantes sont versionnées : une compromission ou un chiffrement malveillant détecté tardivement n'écrase pas les versions précédentes.
Points d'attention
- Le chiffrement vers le cloud est effectué avant l'envoi (chiffrement côté client), pCloud ne reçoit que des données déjà chiffrées.
- Les identifiants de synchronisation sont stockés dans Vaultwarden, jamais en clair dans les scripts (voir
configs/backup/pcloud-sync.sh.example). - Un test de restauration est effectué périodiquement pour valider que les sauvegardes sont exploitables (et pas seulement « présentes »).