diff --git a/README.md b/README.md index 5011c10..aa32613 100644 --- a/README.md +++ b/README.md @@ -1,47 +1,217 @@ -# Prez backup 20231103@labomedia +## intro -## Quotes / Citations -- "There is only two type of person, those who backup and those who ever have data loss" +quote \"There are only two types of persons, those who backup and those +who ever have data loss\" -## Pourquoi des backups ? -* Tout materiel fini par mourrir un jour (hdd VS ssd) -* En cas de vol / perte -* En cas de panne du systeme -* Bitrot -* Pouvoir revenir à un état précédent (upgrade) +### Pourquoi faire des backups ? -## Matériel -* Support -* RAID : longétivité -* Stratégie +- Tout matériel finit par mourir -## Règle 3-2-1 -* 3 copies de la donnée -* 2 différent type de stockage -* 1 copie hors site +- Perte / Vol -## HowTo version minimaliste ? -* automatique -* léger -* rapide -* Rsync sur plusieurs machine tous les jours +- Panne système + +- Bitrot ( data rot, disc rot, scrubing ) + +- Retrouver un état antérieur ( bourde, upgrade, etc\... ) -## HowTo version acceptable -* compression -* deduplication -* chiffrement -* conservation roulante: -| Nombre backup | Période | -| ------------- | ------- | -| 24 | Jour | -| 7 | Semaine | -| 4 | Mois | -| 12 | Année | +### Matériel et coût + +- clé usb 10€ + +- disque dur (ssd ou à plateau) 50€+ + +- serveur dédié avec 2 disque  75€ ?? + +- Caractéristiques matérielles différentes ( disque dûr, SSD, carte + mémoire, etc\... ). + +### Logiciel et coût + +- Abonnement cloud 5To  30€ + +- RAID (Redundant Array of Independent Disks): découpage en fragments + de données répartis sur différents supports de stockage (hdd ou ssd) + +- RAID is not backup + +### Réflexion coût / service + +- Réflexion sur la stratégie à adopter ( coût vs criticité des données + ) + +- Le moins cher en ressources humaine, coûts de mise en place est + probablement le cloud (beurk) + +- Sinon les clé usb bien rangées ( Archivage ) + +## Méthodes +### Règle 3-2-1 (théorie old-school) + +- 3 copies de la donnée (pour pouvoir perdre un peer sans danger + perdre la redondance) + +- 2 différents types de stockage + +- 1 copie hors site (limiter les soucis en cas d'inaccessibilité d'un + site, redondance géo) + +- Backups par jwz: https://www.jwz.org/doc/backups.html + +### la rache + +- Copie sur plusieurs disque / clé usb + +- On lance les copies manuellement + +### Debrouille + +- automatique (tous les jours, avec cron ou timer systemd) + +- léger (on évite les downtime à chaque backup) + +- rapide (au minimum plus rapide que la fréquence souhaitée) + +- rsync ou rclone vers plusieurs machines quotidiennement (c'est mieux + que rien donc go) + +### Sympa + +- compression + +- déduplication + +- chiffrement + +- conservation roulante chaque heure (24J / 7 semaine / 4 mois / 12 + année) -## Comment faire version pro (zfs / btrfs) -* dedup block -* snapshot ro immutable -* rapide et leger -* scale beaucoup mieux +- Utilisation de borgbackup, burp ou autre appli + +- On lance les copies automatiquement (cron ou timer systemd) + +- Plus simple pour comparer les résultats + +### La version pro® (zfs / btrfs) + +- snapshot immutable niveau FS + +- Transfert des snapshots niveau FS (zfs-send \| zfs-receive, pareil + en btrfs) + +- Possibilité de transferts incrémentaux (seulement le diff par + rapport au parent) + +- rapide et léger (On privilégie le code kernel plus rapide) + +- déduplication au niveau des blocks (Peux être couteux mais économie + d'espace dans le temps) + +- Résistance au client qui se fait pwner (append only+ro, \"do not + trust the client\") + +- Résistance au serveur qui se fait pwner (scrub coté client ? \"do + not trust the server\") + +- Utilisation de btrbk par exemple + +- On lance les copies automatiquement (cron ou timer systemd) + +## Outils + +### synchronisation + +* rsync + +- un grand classique, présent presque partout, dépends de SSH + +- permet de ne pas retransférer des fichier déjà existant + +- synchronisation : on perds les éditions précédentes + +* rclone + +- rsync évolué + +- transfert vers \"cloud\" : dropbox, google drive, webDAV etc\... + +### roulement + +* borgbackup + +- beaucoup de features + +- revenir à un état précédent tout en évitant de prendre trop d'espace + disque + +- fonctionnement par \"dépôts\" + +``` + Creating archive at "/data/backup/grolem::grolem-2023-10-30" + ------------------------------------------------------------------------------ + Repository: /data/backup/grolem + Archive name: grolem-2023-10-30 + Time (start): Mon, 2023-10-30 03:00:03 + Time (end): Mon, 2023-10-30 03:00:22 + ------------------------------------------------------------------------------ + Original size Compressed size Deduplicated size + This archive: 3.60 GB 1.93 GB 184.49 kB + All archives: 20.18 GB 10.79 GB 1.24 GB + + Unique chunks Total chunks + Chunk index: 62784 741059 + ------------------------------------------------------------------------------ + Keeping archive (rule: weekly #1): grolem-2023-10-30 Mon, 2023-10-30 03:00:03 [66ff9009686bdb24e2b602f67ecd59f4463b7518aac8f9d62f387ca70f43726e] + Keeping archive (rule: weekly #2): grolem-2023-10-29 Sun, 2023-10-29 03:00:02 [f309d84b1d127fee5e6a05ef65df2458d72ef874a4a93756a9819231ed9ad8a2] + Pruning archive (1/1): grolem-2023-10-22 Sun, 2023-10-22 03:00:04 [fd4923bc1eaaae348870219d7d232138e5065adaaa66dd6fe9b84d87f01b05fa] + Keeping archive (rule: monthly #1): grolem-2023-09-30 Sat, 2023-09-30 03:00:03 [c09faa0dc065283492cd7d29afbd61096c04c11641afc601afd512ba35b99403] + Keeping archive (rule: monthly #2): grolem-2023-08-31 Thu, 2023-08-31 03:00:03 [29e872676ffb3befc569912aedbde0aff95aee4611276195a67e64e6c57564da] + Keeping archive (rule: monthly #3): grolem-2023-07-31 Mon, 2023-07-31 03:00:03 [639ff1e8d401b0c81be6487053cc4c150fcee802210084f3f3560bf0f85e2a15] + Keeping archive (rule: monthly #4): grolem-2023-06-30 Fri, 2023-06-30 03:00:02 [bb17a1108891315838443b05388775cdf127204276e27751e33a00e1e378c27d] +``` + +* burp + +- proche borgbackup mais utilise un serveur de backup central, ne passe pas par ssh + +- \"timer\" + heure à laquelle le serveur opère : le serveur décide de + si c'est le môment de faire un backup + +``` + -------------------------------------------------------------------------------- + Start time: 2023-02-27 18:05:01 + End time: 2023-02-27 23:53:14 + Time taken: 05:48:13 + New Changed Duplicate Deleted Total | Scanned + ------------------------------------------------------------ + Files: 0 6 12 0 18 | 18 + Meta data: 6 0 0 6 6 | 6 + Directories: 0 0 1 0 1 | 1 + Grand total: 6 6 13 6 25 | 25 + ------------------------------------------------------------ + + Messages: 0 + Warnings: 0 + + Bytes estimated: 209214636032 (194.85 GB) + Bytes in backup: 209214637062 (194.85 GB) + Bytes received: 1873139099 (1.74 GB) + Bytes sent: 19359725 (18.46 MB) + -------------------------------------------------------------------------------- + 2023-02-27 23:53:14 +0100: burp[335114] Backup completed. +``` + +## Conclusion + +- Beaucoup de solutions, des approches différentes + +- rsync, rclone : synchronisation + +- borgbackup, burp : roulement + +- ZFS, btrfs : optimal, mais demande de l'infra + +- Quelles données sont importantes ? Quel moyens pour assurer leur + cycle ?