et si je te chiffre ton(tes) snapshots (second espace de stockage) en première phase de l’attaque ?
Tu réanimes la bête comment ?
Personnellement je contrôle l’intégrité de mes depots borgbackup AVANT de les synchroniser (rsync pour externalisation sur un autre site physique ) … au moindre doute de cryptage ou de corruption : je ne synchronise pas … une alerte part illico … car cela peut signifier que l’on s’est fait ouvrir
Note : je vais surement évaluer la possibilité de faire un double depot borkbackup, un interne l’autre externe.
Et si on te chiffre ton second dépot borg backup en première phase d’attaque ? C’est pas le même problème ?
A partir du moment où quelqu’un a un accès suffisant sur une machine pour cryptolocker, je pense qu’il n’y a pas plus grand chose à faire pour cette machine et ce qu’elle contenait.
Non je ne mélange pas tout, au contraire je prends la problématique dans son ensemble. Ça s’appelle faire de l’ architecture système (ou urbanisation du si).
La sauvegarde (chiffrées ou pas) fait partie intégrante de la sécurité.
je n’ai pas de second dépôt borgbackup (borgbackup permet de faire de la rétention de données sur 5 ans, ce n’est pas une copie, ni une synchro ni un snapshot). Mon externalisation se base sur une synchro du dépot (c’est différent), cette synchro (copie ) des dépots est sur un autre site, physiquement isolé .
Et logiquement aussi … la solution de sauvegarde BorgBackup (n°1) ne PEUT PAS voir , ou accéder à la solution de sauvegarde n°2 déporté .
Donc physiquement ou logiquement : la compromission des dépots BorgBackup NE PERMET pas une compromission de la copie externe. (là c’est physique et logique …).
Le truc que j’aimerai implémenter c’est pouvoir faire un snapshot sur proxmox (la prod) et pouvoir travailler avec borgbackup sur ce snaphsot laissant tourner la prod pendant le backup , tout cela au niveau système de fichier … donc pouvoir rentrer dans le snapshot
Pour répondre au poste initiale, je m’intéresse , bien entendu ,aux snapshot pour ne pas pertuber la prod. (je n’ai que 60 utilisateur sur une des insatnces nextcloud : mais quand on va augmenter en volumétrie … je vais avoir un temps de backup long … c’est sur un autre réseau mais si on peut améliorer).
Voilà ou j’en suis sur du ceph/RBD :
Par contre cela coince au moment du montage sur le système racine de l’hyperviseur :
rbd snap ls cephPool1/vm-106-disk-0
==>
SNAPID NAME SIZE TIMESTAMP
32 Backup28102019 32GiB Mon Oct 28 19:46:00 2019
trouvé ! (forum proxmox, souci sur option de montage)
Pour ceux qui veulent bosser sur le système de fichier du CT (LXC, conteneur) via le snapshot fait par proxmox (sur du Ceph/RBD …), comme çà a on peut faire les backup en pleine production , en pleine journée … (à condition d’avoir bien monté son cluster avec un réseau dédié à la sauvegade)
je suis en train de bien regarder le cli, de vzdump … (en plus de snapshot)
Question si tu dumpes un NextCloud (ou un seafile) de 900Go (et plus!) : auras tu de la place pour le fichier tmp pour la compression ?
Je vais tenter d’implémenter le backup via un snapshot mais c’est pas parfait.
« snapshot mode
This mode provides the lowest operation downtime, at the cost of a small inconstancy risk. It works by performing a Proxmox VE live backup, in which data blocks are copied while the VM is running. If the guest agent is enabled (agent: 1) and running, it calls guest-fsfreeze-freeze and guest-fsfreeze-thaw to improve consistency. »
Avez vzdump vous n’avez pas des problèmes d’IO? je backup mes containers LXC avec un backup mode: snapshot sur le serveur de sauvegarde d’OVH mais cela me génère un IO proche de 100% ce qui n’est pas top en terme de performance… Vous n’avez pas constaté ce type de problème?
Pourtant tu les paies bien … 100€ par mois
J’ai tout viré de chez eux, ils prennent les petits pour des poires … et comme je n’en suis pas une : j’auto-héberge tout sur 2 liens VDSL.
Tu peux aller voir ma conf. ca marche bien promox avec ceph.
il faut juste choisir les bons ingrédient set appliquer la bonne recette … enfin pour l’instant j’en suis content.
Salut à toutes et à tous,
j’ai fait pas mal de recherches ces derniers jours à propos des méthodes de backup au sein de proxmox, afin de faire un script capable de sauvegarder les conteneurs avec borg en profitant à fond de la déduplication.
L’idée de @cquest m’a mis sur la bonne voie :
Le script que j’ai fait fonctionne plutôt bien, il est capable de gérer à la fois les subvols et le volumes raw, c’est pile poil ce qui me fallait.
Cependant je suis confronté à un dernier problème de taille ! Les conteneurs LXC sont en mode « unprivileged », les uid/gid des fichiers du conteneur ont donc une valeur élevée (>100000). Or cela pose problème à borg, en dépit il réinitialise toutes les valeurs à 0:0. Ainsi quand le conteneur sera restauré depuis une archive borg, tous ses fichiers appartiendront à root !
Pour pallier au problème, j’ai pour l’instant trouvé une bidouille, consistant à recopier (avant de lancer borg) tous les fichiers dans un dossier /nimporte depuis le point de montage temporaire, puis éxecuter :
for file in $(find /nimporte); do chown $(($(stat $file -c%u) - 100000)):$(($(stat $file -c%g) - 100000)) $file; done
Cette technique marche mais elle est très peu performante.
J’ai donc entrepris l’étude du code de vzdump car dans les .tar qu’il fabrique, les uid/gid commencent à 0:0, ce qui rend ces archives « restorables » sous forme de conteneur privilégié ou non (on a le choix), le tout dans un délai imperceptible. Malheureusement, après la lecture complète du VZdump.pm et de ses dépendances je ne sais toujours pas comment il fait cette modification sur les fichiers.
Je n’ai rien trouvé d’intéressant sur le web à ce sujet … Avez-vous une idée, des pistes à me suggérer ?
Merci d’avance <3
c’est ce que tu souhaites ? (pour mon archi. c’est pile poil ce que je dois faire pour un full backup, ce que je ne fais pas encore)
Après je vous cache pas que c’est … pas des trucs triviaux. On est dans la grosse cuisine.
Ça y est j’ai trouvé mon erreur ! C’était tout bête, j’ai été induit en erreur par plusieurs issues ouvertes où les problèmes présentés était semblables au mien (https://github.com/borgbackup/borg/issues e.g. #1869#1751).
Mon soucis venait du fait que j’avais mal compris l’option --numeric-owner en effet si elle est utilisée lors de la création d’une archive elle ne sert qu’à garder les permissions des fichiers.
J’ai appris ensuite que lors de l’extraction d’une archive, Borg ne retranscrit pas directement l’uid des fichiers, il va d’abord vérifier que chaque uid correspond à un utilisateur existant sur le système. D’après ce que j’ai compris, s’il remarque que l’uid du propriétaire d’un fichier n’existe pas sur le système alors il le remplace par celui de l’utilisateur qui a lancé Borg.
Par conséquent l’option qui convient pour garder les uid intactes lors de l’extraction est --numeric-owner ! e.g. borg extract --numeric-owner ssh://user@backup-server.eluker.io::pct1000-2019-11-09T23:13:57
Bref c’était bien plus facile que prévu, merci @anon6747921 pour l’idée du backup en mode pull, je vais peut-être choisir cette méthode.
Désolé d’avoir fait perdre du temps à ceux qui ont cherché à résoudre mon problème.
… salut mablr.
Je dois refaire mon code de backup en vue d’atteindre l’objectif de faire un backup qui permette de restorer le conteneur entier (tout son file system AVEC les bonnes permissions etc) : j’ai du taf !
Car j’avais pas percuté le coup des uid/gid, car je sauvegarde /etc /root /var /home , donc les données et fichiers stratégiques. Donc je peux repartir from scratch mais c’est long.
D’ou l’idée de faire un snapshot et donc pouvoir bosser peinard (offline pendant la prod. sans interruption de service) sur un montage local à l’hyperviseur.
je dois remettre le couvert pour rajouter une méthode de backup pour borg. (j’ai juste eu à restaurer quelques fic. de conf et une instance nextcloud pour tester ma solution)
Edit : donc tu confirmes que borg stocke bien les info uid/gid lors du backup ?
(tout se jouerait à la restauration : --numeric-owner)
(