Reprise du message précédent :
Bon ben voilà, mon backup s'est bien déroulé, hum hum
 

Comment dire... ça ne va pas trop être possible au quotidien je pense
Plus de 16h de moulinage, dont une dizaine pour faire le dump initial (donc à chaque fois, avec le serveur en quasi PLS pendant une bonne partie du temps), va falloir envisager autre chose
 
A priori il y a moyen de rajouter un ou des fichiers .pxarexclude dans le conteneur pour demander l'exclusion du backup via PBS... mais à mon avis ça ne va rien changer dans la mesure où c'est le dump initial qui est long, pas le transfert via PBS.
 
Me reste donc le déplacement de /home (c'est là que j'ai 260Go sur les 280 en gros) dans un point de montage/stockage séparé.
Je le sens moyen, notamment parce que dans /home j'ai aussi le dossier d'accueil (avec .ssh/authorized_keys) de mon user qui gère le serveur. Donc si je restaure un backup du conteneur sans le point de montage de /home, je ne peux plus me loguer...
 
Des suggestions ?

Séparer système et données: système léger et données synchronisées.

Ca c'était un peu implicite vu la problématique. Mais concrètement ?

Perso j'ai mes données au niveau de l'OS du proxmox et je "bind" des dossiers dans mes conteneurs.
Les CT n'ont donc que les binaires/programme/SQL et les data/fichiers sont sur mon stockage.
 
Du coup je backup que les CT qui sont léger.
Et j'ai un CT qui a un/des bind sur tous le dossiers à backup et qui fait tourner une solution de backup qui externalise tout ça : donnée fichiers + les backup des CT vers un stockage externe chiffré/compressé (un accès sFTP chez un pote, pour qui je fais pareil en échange)
 
après perso j'envoi simplement ça ailleurs, j'ai pas prévu de "PCA" en cas de panne à la maison (la rapport prix/nécessité m'intéresse pas perso)

Ansible pour créer les VMs/containers comme ça pas besoin de backup.
Les données sauvegardées séparément.

 
Je suis un peu dans le même genre de réflexion. De ce que j'ai pu lire jusqu'à présent, il semble plus efficace de passer le(s) disque(s) à la VM via un passthrough, quand c'est faisable. C'est alors l'OS du NAS dans la VM qui gère le filesystem.
Mais j'ai vu quand même beaucoup de tuto qui partent sur le principe de : je crée mes disque sur Proxmox, puis je virtualise les disques pour les passer à la VM. Et j'ai pas mal vu aussi que c'était "le mal", souvent sans plus d'arguments ...
Curieux d'avoir vos avis, ça dépasse encore mes compétences pour l'instant.

J'ai vu aussi qu'il était possible de passthrough la carte sata.
A voir les modèles compatibles avec le Passthrough

Dites, ça tournerait PBS sur un petit NUC à base de J3455 et 8 Go de RAM ?

Toujours sur mon histoire de déport de données, voilà l'idée à laquelle je pense :
1/ je créé un nouveau point de montage, par exemple un disque de 500 Go que je monte dans /home2 de mon LXC
2/ je déplace tous les dossiers de mes sites web dans ce /home2
3/ je fais des liens (ln) pour que /home/xyz pointe vers /home2/xyz l'idée étant de garder quand même /home/monuser en local dans le lxc (avec les clés publiques & co) et d'avoir les données dans ce second "disque virtuel" qu'il est possible d'exclure des backups (case à cocher dans la GUI) + ne pas avoir de la config à refaire dans tous les sens (vhosts apache & co)
 
ça semble cohérent où dangereux d'utiliser des liens plutôt que des dossiers/fichiers en dur ?

 
Données hors container pour pouvoir le sauvegarder facilement et données simplement sauvegardées par rsync.
Ou si c'est trop compliqué, mais ça a pas mal de défauts, sauvegarde d'un container de base, puis déploiement et synchro des données à part.
 
Après je ne connais pas la solution PBS mais peut être a-t-elle un moyen de gérer vraiment de l'incrémentiel/différentiel avec un minimum de performances ce qui ne semble pas être le cas chez toi.
 
edit: Si PBS permet d'exclure un disque, tu as la solution.

En fait PBS permet d'exclure des fichiers dans la sauvegarde finale (de ce que j'ai compris), mais comme ça commence par faire un gros dump de tout avant de faire la synchro, ça ne va pas m'aider.
 
Bon je pense que je vais tenter le truc évoqué plus haut, mais déjà faut que je déplace le volume initial, et comme on est sur un kimsufi, de disque à (même) disque c'est lent... avec 300Go à chaque fois c'est une demi journée la moindre manip

 
Sans soucis, ça tourne chez moi sur une VM dans un Synology DS1821+ avec 2cores et 4Go de RAM (après ça suffit pour mon utilisation, cad 4-5 containers et autant de VM), si tu as plus ce sera peut être un peu juste.

Merci pour ton retour, je vais pouvoir recycler mon ancien NUC

J'ai aussi songé à extraire les données de mon lxc Nextcloud.
Je backup 700Go chaque jour ça prend 1h.
Par contre forcément avec du SSD et du réseau 5Gb j'ai pas vraiment de bottleneck. Le backup se fait vers un tmp sur NVMe puis transféré vers le NAS.

Le plus long c'est de transférer les 650Go de backup tous les jours vers Hertzner. Ca prend environ 8h.

Ah ouais ça dépote !!!
C'est là qu'un PBS te permettrait d'éviter d'avoir 650Go chaque jour mais juste le delta.
 
Moi j'avance doucement,
j'ai créé mon 2nd volume, et commencé à déplacer mes sites web
le coup du ln -s /home2/sitexyz /home/xyz ça a l'air de fonctionner. Apache ne couine pas, il n'y a pas de pb de droits...  
il faudra juste voir si le backup  (vzdump) suit ou non les liens symboliques. S'il les suit il faudra que je me tape au choix :
- toute une reconf de tout un paquet d'apps (vhosts, config de seafile, ...) avec à mon avis tout un tas de problèmes à la clé
- vider complètement /home et tenter le monter mon home2 à la place de /home...

J'ai corrigé ça prend 1h, j'avais pas les yeux en face des trous. Mais quoi qu'il en soit ça envoie du lourd ouais.
J'ai pris un serveur chez OneProvider, j'hésite à y installer PBS

Bon le coup des liens symboliques c'est bon ça fonctionne.
 
J'ai donc :
- /home normal avec le dossier de mon user, j'ai aussi gardé un phpmyadmin car comme j'ai mysql qui tourne, je préfère avoir un outil prêt à l'emploi dans la resto de backup
- /home2 avec tous mes dossiers de sites et applications web, seafile inclus
- des liens symboliques pour avoir tout ce petit monde accessible depuis /home
- le LXC configuré pour que le point de montage/disque virtuel monté dans /home2 ne soit pas sauvegardé (case à cocher "backup" décochée).
 
Je viens de faire un backup ça a été BEAUCOUP plus rapide et là actuellement le tar final ne fait plus que 5Go !
 
En parallèle j'ai mis en place un rsync depuis mon serveur à la maison pour faire un miroir de /home2 du serveur distant. En timant bien les heures de réplication de mon serveur @home (car lui aussi est répliqué) je devrais avoir 2 jours d'historique. (Genre réplication node1->node2 @home à 1h du mat et rsync pour récup les maj de /home2 distant à 4h du mat).
 
C'est pas idéal, c'est pas ce que je voulais, mais vu le type de serveur anémique (kimsufi atom / 1 hdd) en face, c'est probablement le plus pertinent, à la limite en cas de crash ça peut permettre de remettre en prod plus rapidement certaines parties et de prendre un peu plus de temps pour d'autres en restaurant uniquement le vital dans un premier temps et ne pas se taper la resto d'un énorme et unique conteneur.

Poursuite des explorations proxmoxesques sur mon kimsufi :
 
J'ai donc 1 une IPV4 et une série de règles de NAT pour natter ce qui arrive sur l'hôte vers le conteneur LXC qui va bien.
 
Ca marche nickel (ssh, serveur web, mail...)
 
Maintenant si je veux que l'ipv6 fonctionne... je fais pareil (nat individuels des ports) ou alors il y a mieux ?
 
Dans le manager kimsufi j'ai une ipv6 :
2001:42e0:5:4a5c::1  (j'ai modifié un peu)
 
Il y a moyen de faire des trucs cools pour attribuer une ipv6 unique à mon conteneur et tout natter ce qui arrive sur cette ip vers le conteneur ?

C'est pas un /64 sur Kimsufi ? J'ai du mal à croire qu'ils ne donnent qu'un /128 (soit une seule IPv6)...

Probablement. Mais je n'ai aucune idée de comment mlettre ca en place au niveau de proxmox (hôte, conteneur...)

J'ai jamais réussi à choper une IPV6 fonctionnelle sur mes CT.
Les IP pointent toutes vers l'host proxmox mais après les routages et tout le bazar  

https://medium.com/@nanda.adiyatma2 [...] 9beb43b46a

 
Propre    
Merci LibreArbitre

Super
A lire en détail et à tester...

Ça fonctionne, il faut juste remplacer par tes IP et suivre le tuto dans l'ordre.
La partie ipv4 / DHCP / dnsmasq n'est pas utile pour ce que je voulais, j'ai zappé.
Pour les commandes de routage il ya un peu de marge d'amélioration en les mettant dans le post-up des interfaces, mais là je verrai ça plus tard.

Mode boulet du jour :
Maintenant que j'ai un second volume avec mes données dedans, je voulais réduire le volume du rootfs. Je l'ai déjà fait pour un conteneur précédent il y a quelques mois et j'avais mes notes.
1/ backup du conteneur
2/ suppression du conteneur
3/ resto du conteneur avec une option "pct restore blabla -rootfs local:50" pour 50 Go au lieu des 850 initiaux
La suppression de l'étape 2 est nécessaire car sinon ça couine que l'id est déjà utilisé. Je fais bien attention à ne pas cocher la suppression violente des volumes "non référencés" ou truc du genre.
Je restore donc, je vais voir s'il faut réattacher manuellement le volume de mon /home2 ... ah tiens il n'y a plus de volume, tout a été effacé ! RHAAAAAAAAAAAAAAAAAAAAAAAAAA
 
Bon ben au moins c'est direct, je peux tester mon système de restauration de backup via rsync réalisé cette nuit... c'est parti pour 300Go d'upload. Dans ce sens j'ai l'impression qu'ovh est plus permissif, j'ai 200Mbps stable. 90Go par heure ça va donc prendre un petit moment... Comme je disais hier, l'avantage c'est que je peux choisir de commencer par certains dossiers.
 
Sinon, moralité : ne pas supprimer le LXC source, restaurer le backup sous un autre id (c'est pas vital en fait le nom, de toute façon il faut se retaper la création des tâches de backup) et trouver un moyen ensuite (renommage, édition de fichier de conf) de passer l'ancien disque au nouveau conteneur)

Pour mon LXC Nextcloud, je fais un snap zfs via Sanoid toutes les nuits du volume du container et j’utilise Restic sur le snap.
 
Restic gère le delta, la rétention, la purge et envoie ça en ssh sur le nas d’un pote ainsi qu’en local

 
Intéressant ça. En effet un snap ZFS c'est quasi instantané normalement, c'est un truc que Proxmox pourrait améliorer dans sa GUI (automatisation, export).
 
J'ai regardé rapidos restic ça a l'air pas mal (ça me fait penser à borg que j'avais un peu testé). J'imagine qu'il y a moyen d'automatiser tout ça pour ne aps avoir besoin de saisir le mot de passe du repo à chaque fois.
 
Je viens de faire un snapshot manuellement (depuis la GUI de proxmox) pour voir
 
Ensuite :

 
ok
par contre forcément si je fais un ls de là où est monté rpool/storage (cad dans /storage) ça me donne :

Comment restic accède au contenu du snapshot ? il faut le monter quelque part ?
 
J'avais cru comprendre qu'on pouvait accéder à genre /storage/.zfs/snapshot mais chez moi le dossier est vide

 
J'ai la même stratégie mais faute de ZFS ce sont des snapshots proxmox appliqués sur des VM et LXC stockés sur LVM Thin, ça doit prendre moins d'une minute par VM je crois, et pas d'interruption de service.
 
Et pour le backup incrémental du volume de données de mon nextcloud j'utilise avec satisfaction duplicati qui m'avait été recommandé ici. ça prend 6'50 pour 620Go de fichiers à analyser.

Bonjour
Je souhaite créer un lxc InfluxDB avec Proxmox  (installé sur un NUC) mais je souhaiterais que la base de données soit stockée sur mon NAS (conservation des historiques sur plusieurs années).

j'ai déjà défini dans Proxmox un espace de stockage NFS vers mon NAS dans lequel sont actuellement stockés les backup d'une VM Proxmox.

Est-ce que je peux définir un autre espace de stockage dans mon NAS et, au moment de l'installation du lxc  InfluxDB, le sélectionner lorsque il pose la question "Pool Storage du Container Storage" ?

Dites, c’est fiable comment le passthrough d’un disque physique vers une VM ?
 
J’ai une VM Windows qui roule un service quelconque a laquelle j’ai passé deux disques physiques en passthrough. Les disques étaient déjà formatés en NTFS donc j’ai juste eu à les attacher. Ça c’était il y a un moment, quelques mois peut être.  
 
Aujourd’hui, j’ai démonté un des disques de la VM à chaud (pas bien?) car je voulais le formater pour le mettre sur une autre VM (Linux). Malheureusement ce n’était pas le bon, alors je l’ai remonté. J’ai démonté le bon, formaté, ajouté à mon autre VM, jusque là, ça va.  
 
Puis j’ai voulu transférer les datas du premier disque (celui démonté par accident donc) vers le second au travers d’un share SMB entre les deux VM. Et la j’ai constaté que plus de la moitié de mes datas avait disparue. Je parle de dossiers vides au lieu de contenir des fichiers ou de fichiers illisibles.  
 
Alors : est-ce que c’est du au passthrough qui était en place depuis plusieurs mois ? Au démontage sauvage accidentel ? À Windows ? Le disque est en train de mourir ?  
 
Bref avant de remonter mon nouveau setup je m’interroge sur le passthrough.  
 
D’ailleurs, mon nouveau setup (à supposer que mes deux disques sont ok), ça serait quoi le mieux pour qu’un conteneur accède au données de ces disques et que j’ai aussi un partage Samba ?  
 
Mon plan initial et en cours, c’est de créer une VM OpenMediaVault avec passthrough des disques. La dessus de crée un share NFS pour que le conteneur Linux accède au données et un share Samba pour accéder aux donnés depuis un PC ou Mac normal.  
Ça me permettra d’ajouter facilement un RAID5 dans quelques temps: passtrhough des 3 disques à la VM OpenMediaVault, création d’un Raid, share, etc.  
 
Est-ce qu’il y aurait une méthode plus simple et/ou plus fiable ? Genre monter les disques sur l’OS Proxmox et binder le conteneur LXC ? Et un autre conteneur pour le Samba ?

Éteindre la VM avant d'enlever aurait été plus judicieux, clairement !

Un disque c'est pas comme une clé USB

Ou au moins démonter le disque, je sais…  
 
Mais ce qui est fait est fait, juste à ne plus recommencer.
 
Bref ma question reste toujours comment gérer de grosses quantités de donnés avec des conteneurs?

perso j'aime bien que ce soit l'hôte qui gère les disques, pour que justement les vm/conteneurs soient le plus possible agnostiques du matériel.

 
C’est une solution que j’envisage, mais je ne sais pas trop comment la mettre en place. J’ai essayé de créer un RAIDZ avec ZFS mais après je ne sais pas trop quoi faire avec pour que les conteneurs y accèdent.
 
Édit : en fait je viens de vérifier et toutes mes applications pourraient rouler en Docker… alors je me demande si je ne prends pas un virage à 180 et je passe tout en Docker, donc sans Proxmox. Dans TrueNAS par exemple ou autre chose.
Pas le temps de checker ça ce week-end mais je vais y réfléchir !

 
Tout à fait possible et c'est ce que je fais. restic supporte qu'on lui passe un ficher avec la clé en argument. J'ai écrit un script qui fait tout ça
* lecture de la conf du job de backup
* arrêt ou pas du LXC
* lancement de sanoid pour le snap. Sanoid gere aussi l'effacement des vieux snaps
* relance du LXC si arreté précedement
* lancement de restic
 

 
 
Tu te trompes de path pour le snapshot. Si tu snapshotes rpool/storage/subvol-500-disk-0 le snap sera dans ton point de montage /storage/subvol-500-disk-0/.zfs/snapshot
 
Exemple chez moi : /data/volumes/lxc/subvol-101-disk-0/.zfs/snapshot/autosnap_2023-03-09_02:37:07_daily

https://gist.github.com/ajmassi/e68 [...] f073921352

Ah forcément ! Merci. Je vais aller voir ça (entre temps j'ai viré le snap,  faudra que je recommence.)

Bon si ca peut intéresser au moins une personne ,  apres qq heures , j'ai enfin reussi a mover mon HA depuis une VM proxmox à une VM pimox (pi 400)
 
 Systématiquement apres chaque restore de backup HA, je ne retrouvais jamais HA sur la VM pimox.
 
 Le truc a été de restaurer le backup HA de la VM proxmox sur un Raspberry 3 , faire un backup HA depuis ce Raspberry puis restaurer ce backup sur la VM pimox.
 
Bon maintenant jésuite entre rester sur le PI3 et la VM pimox

Question bête ...
 
Je suis sous Proxmox 7.2-7 (Linux 5.15.39-1).
 
Je me rends compte que sur le host, je ne trouve pas mes périphériques usb dans /dev/serial/by-id/
J'ai même pas de /dev/ttyUSB ....
 
Je ne comprend pas ...
 
Je cherche à figer sur un container LXC un périph qui sera mappé sur un docker. Mais si j'ai pas le /dev/serial/by-id/ , ca va être pénible je sens ....
 

En effet, je n'avais jamais fais gaffe.
En passant par la gui il te trouve tout ce qu'il faut normalement.
Édit : pour les vm en tout cas.
En effet pour un lxc c'est une très bonne question...
Ca a l'air un peu le bordel en fait (droits), voir le forum proxmox.