## intro quote \"There are only two types of persons, those who backup and those who ever have data loss\" ### Pourquoi faire des backups ? - Tout matériel finit par mourir - Perte / Vol - Panne système - Bitrot ( data rot, disc rot, scrubing ) - Retrouver un état antérieur ( bourde, upgrade, etc\... ) ### 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) - 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 ?