Logo journal du hacker middle
  1. 12
  1.  

  2. [Comment removed by author]

    1. 2

      Le problème du disque externe, c’est de penser à le brancher pour effectuer une sauvegarde. Et s’il est toujours branché, on a juste une tolérance à la panne. C’est la méthode que j’utilisais avant, sauvegarde semi manuel avec rsync, mais quand ma mère à été cambriolé, et donc son PC + son HDD de sauvegarde (qui était dans une autre pièce) ont été volé, ba elle à perdu plusieurs années de photos et de documents.

    2. 1

      Tu peux être relativement serein avec ta configuration.

      De mon côté j’utilise BorgBackup depuis un moment, mais j’utilise aussi Kopia depuis environ 6 mois en complément.

      1. 1

        De mon coté, c’est un peu plus simple, avec uniquement BorgBackup :

        • Les machines qui ont suffisamment d’espace disque font un backup sur leur propre disque (accès rapide)
        • Chaque machine (locale ou distante) fait un backup sur mon NAS (qui est chez moi)
        • Chaque machine (locale ou distante) fait un backup sur un serveur Kimsufi (pour avoir une copie distante)

        Trois machines locales (desktop, serveur LAN et NAS) et une machine distante (Kimsufi) sont sauvegardées de cette manière (système complet en excluant des répertoires trop gros dont je peux retrouver/regénérer le contenu simplement). Pour mon téléphone, les backups sont manuels via USB (script jmtps + rsync + borg), parce que 4G/Wifi/Bluetooth ne sont jamais activés. Il y a tellement peu de choses dessus que ça suffit.

        Notes :

        • Les deux ou trois backups de chaque machine sont indépendants : La corruption d’un repo ne touche pas les autres.
        • Chaque backup se lance une heure après la fin du précédent. Le load se lisse tout seul avec le temps.
        • À l’utilisation, je ne sens aucun impact, que ce soit au niveau utilisation CPU/Disque ou connexion internet (ADSL 1.3 Mbps down / 473 kbps up).
        • À la fin d’un backup, les stats sont envoyées dans InfluxDB (alerting via Grafana) et par mail. Selon le statut du backup, le mail est rangé/marqué comme lu automatiquement (Success/Warning) ou laissé non lu dans la boite de réception (Erreur).

        Par rapport à ce que tu as mis en place, je vois deux améliorations :

        • Avoir au moins deux backups indépendants : Actuellement, tes “backups supplémentaires” (Borg du répertoire syncthing puis synchro vers Google Drive) sont chacun basés sur le précédent. Une corruption du premier se propagera donc dans les autres.
        • Ajouter du monitoring pour être prévenu des anomalies (backup échoué, repo qui grossit très vite, absence de backup sur une certaine période, etc.).
        1. 2

          Merci pour ton retour, je suis d’accord avec toi sur le fait que mes backups supplémentaires sont des backups de backups, donc risques de corruptions. Pour syncthing, ce n’est pas un backup, mais une synchro, ce qui n’est pas totalement pareil, le risque de corruption est quasi null.

          Pour ce qui est de ta méthode, pour les serveurs oui c’est faisable, mais pour du desktop/laptop, c’est plus compliqué, comme dis, ils ne sont allumés que quand je les utilisent, et je ne veux pas que ça utilise trop de ressource (compression + chiffrement), et mes PCs ne sont pas des plus performants (par exemple un rclone mount bouffe tout mon CPU).
          C’est pour cela qu’une synchronisation me semble le mieux pour le moment, ce n’est pas une sauvegarde, juste une syncrho 1:1, avec une rétention des fichiers à 2 jours en cas de suppression sur la source.

          Comme dis dans mon article, ma solution n’est pas un choix arrêté, mais j’ai déjà vu une faille dedans, si je perds tout chez moi, pour restaurer il faut que je télécharge toute l’archive de duplicati (pour l’instant environ 1To), alors qu’avec une solution comme restic ou borg, je pourrais monter et récupérer ce que j’ai besoin.

          Pour le scheduling, je ne sais pas encore, je pense finir par partir sur ansible, qui se connectera à chaque machine pour faire les sauvegardes, ce n’est pas sont rôle normalement, mais on va dire que si, cependant, ce n’est pas encore défini.

        2. 1

          Perso, pour pas que ça se chevauche, je fais tout depuis le serveur (un so you start à pas cher). C’est lui qui fait le tour de tout le monde la nuit, et qui fait ses rotations pendant la journée, une fois fini le tour. Avec un petit fichier de config à mettre à jour à chaque nouvelle VM et sa clé publique à rajouter automatiquement au script de déploiement. Pas sûr que ce soit parfait mais jusqu’à présent j’ai toujours récupéré ce que mes clients avaient éventuellement perdu.