Montage serveur domotique

[dcjona]

Bon ben je pense qu'il faudrait un bon tuto pour un système de sauvegarde cohérent de jeedom et des vm sous proxmox non ?
qui s'y colle ?

[bartounet]

J'ai lu ce document concernant la suppression de snapshots : ICI

Pour être franc, je n'ai pas tout compris
Mais j'ai bien l'impression que la prise de multiples snapshots ne serait pas une bonne idée.
La suppression de l'une d'elles génère une consolidation gourmande en ressources qui impacte les performances

J'ai aussi l'impression qu'il est préférable d'effectuer des sauvegardes externalisées de VM, qui logiquement ne pourront être effectuées que s'il n'existe pas de snapshot antérieur
On peut éventuellement prendre un snapshot temporaire avant une mise à jour pour la rapidité de la procédure

Oui
Les snapshots ne sont pas des sauvegardes.
Ils doivent être utilisés sur des périodes courtes.

La bonnes pratique VMWARE est ne ne pas les garder plus de 72 heures.
https://kb.vmware.com/s/article/1025279

Par contre ils sont parfait pour réaliser des changements et revenir en arrière en cas de problème.

Concernant ma sauvegarde j'ai tout dit.
J'utilise ghettoVCB VMWARE ESXi 6.7

Bosquetia à fait un très bon Tuto la dessus : viewtopic.php?f=154&t=40137&p=656558&hi ... CB#p656558

La seule différence c'est que mon DATASTORE de Backup est portée sur un partage NFS de mon NAS ( VM aussi avec des disque en direct)
Cela me permet d'acceder à mes backup depuis n'importe ou et de modifier mon ghettoVCB.conf en direct depuis notepad++

Backup Jeedom vers Mon NAS = Tous les jours à 6h00 du matin ( rétention 7 jours)
Backup de mes VM Vers mon DATASTORE NFS = Tous les jours à 7h00 du matin ( rétention 7 jours)

En cas de crash, redescente dela backup VM via ghettoVCB Restore + restauration Jeedom backup

Ne pas oublier d'externaliser de temps en temps vos backup.
N'ayant pas une grosse connexion, j'ai opté par une externalisation sur disques externes que j’emmène au taff.

[propositionjoe]

Après là je me demande dans quelle mesure on parle de la même chose, y a des utilisateurs de proxmox et d'exsi qui s'expriment en même temps...
Me semble-t-il que proxmox n'entend pas la même chose entre :
- le mode snapshots pour faire un backup https://pve.proxmox.com/wiki/Backup_and_Restore
- et le live snapshots qui permet de constituer une branche dans sa vm https://pve.proxmox.com/wiki/Live_Snapshots

De manière général proxmox recommande d'éteindre pour éviter tout problème, mais déclare que les risques sont néanmoins faibles...

[i-magin]

Merci @bartounet pour tes informations très claires

Concernant le tuto de @Bosquetia, j'aurais vraiment aimé en bénéficier... mais il a "disparu" et c'est vraiment dommage

[Phil56]

J'effectue également une sauvegarde de ma VM ESXi "de temps à autre", avant ou après de grosses modifications
Pour cela, j'utilise la procédure décrite par @Loic qui s'appuie sur ghettoVCB.
Mais la procédure ghettoVCB s'arrête si elle détecte la présence de snapshots

Bonjour,

sur un autre Post, j'expliquais avoir constaté que depuis ma migration vers un nouveau NUC, je n'avais plus ce problème de snapshots avec ghettoVCB. Je ne sais pas si ça vient de mon passage en version 6.7 ou alors plus vraisemblablement la mise à jour du script ghettoVCB.

Je ne sais pas si tu peux faire la mise à jour de ce script pour voir si cela se comporte comme chez moi.

ken@vo
Phil

[Bosquetia]

Du moment que tu as ta backup jeedom c'est bon

Je donne mon expérience professionnelle
Un serveur de bdd sollicité 8 fois sur 10 après une restauration vm, la bdd ne redémarre plus

C'est pour ça qu'on dump toujours la bdd avant la backup
OK peu aussi sur les outil de backup lancer tes scripts avant backup qui stop les services critiques

J'aimerai bien connaitre l'infra du serveur de BDD et la base, car en 25ans de métier, cela fait plusieurs années que l'on a des outils permettant de sauvegarder une VM avec bdd sans souci et sans downtime...
Sans parler des softs de backup ayant des agents pour sauvegarder a chaud aussi

Soit ton outil de backup est capable de dialoguer avec la bdd
Aujourd'hui en effet tous les outils de backup évolué le permettent en installant un agent sur le serveur

Soit il est en est pas capable et dans ce cas tu prends le risque qu'elle soit corrompu

Si la bdd n'est pas sollicitée, en effet y a peu de risque, une réparation de la base suffit souvent.
Mais une grosse BDD sollicitée non...

Apres sauvegarder avec un agent c'est bien joli mais il faut pouvoir restaurer

Tous ces beaux agents de sauvegarde à chaud te garantisse une cohérence mais la plupart des boîtes utilisant ces agents n'ont pas de DBA et le jour de la restauration pleure car ils ne savent pas faire. Et paie une prestation..

Pour ma part je ne suis pas DBA
Donc nous avons fait le choix de ne pas utiliser les agents de sauvegardes bdd

Mais par contre nous laissons la l'obligation et responsabilité à l'éditeur de faire ses dumps et ses restaurations

Mais je ne suis pas DBA, et je suis friand d'apprendre.
Donne moi les liens d'un outil de sauvegarde qui est capable de garantir une sauvegarde/restauration cohérente d'une base de donnée, sans installer d'agent sur la Vm, ni de script qui vont envoyer des commandes à la bdd . !!!

et oui DBA c'est un métier
Et sur toutes les sauvegardes faites bases à chaud avec agent jamais eu de souci pour restaurer... et dieu sait si base de données et industrie pharma c'est important !!

cependant juste une chose, avoir une base de données critiques sans avoir de DBA, le tout dans le monde pro ça fait juste amateur !!

[Bosquetia]

J'effectue également une sauvegarde de ma VM ESXi "de temps à autre", avant ou après de grosses modifications
Pour cela, j'utilise la procédure décrite par @Loic qui s'appuie sur ghettoVCB.
Mais la procédure ghettoVCB s'arrête si elle détecte la présence de snapshots

Bonjour,

sur un autre Post, j'expliquais avoir constaté que depuis ma migration vers un nouveau NUC, je n'avais plus ce problème de snapshots avec ghettoVCB. Je ne sais pas si ça vient de mon passage en version 6.7 ou alors plus vraisemblablement la mise à jour du script ghettoVCB.

Je ne sais pas si tu peux faire la mise à jour de ce script pour voir si cela se comporte comme chez moi.

ken@vo
Phil

c'est bien la dernière version du script

[bartounet]

J'aimerai bien connaitre l'infra du serveur de BDD et la base, car en 25ans de métier, cela fait plusieurs années que l'on a des outils permettant de sauvegarder une VM avec bdd sans souci et sans downtime...
Sans parler des softs de backup ayant des agents pour sauvegarder a chaud aussi

Soit ton outil de backup est capable de dialoguer avec la bdd
Aujourd'hui en effet tous les outils de backup évolué le permettent en installant un agent sur le serveur

Soit il est en est pas capable et dans ce cas tu prends le risque qu'elle soit corrompu

Si la bdd n'est pas sollicitée, en effet y a peu de risque, une réparation de la base suffit souvent.
Mais une grosse BDD sollicitée non...

Apres sauvegarder avec un agent c'est bien joli mais il faut pouvoir restaurer

Tous ces beaux agents de sauvegarde à chaud te garantisse une cohérence mais la plupart des boîtes utilisant ces agents n'ont pas de DBA et le jour de la restauration pleure car ils ne savent pas faire. Et paie une prestation..

Pour ma part je ne suis pas DBA
Donc nous avons fait le choix de ne pas utiliser les agents de sauvegardes bdd

Mais par contre nous laissons la l'obligation et responsabilité à l'éditeur de faire ses dumps et ses restaurations

Mais je ne suis pas DBA, et je suis friand d'apprendre.
Donne moi les liens d'un outil de sauvegarde qui est capable de garantir une sauvegarde/restauration cohérente d'une base de donnée, sans installer d'agent sur la Vm, ni de script qui vont envoyer des commandes à la bdd . !!!

et oui DBA c'est un métier
Et sur toutes les sauvegardes faites bases à chaud avec agent jamais eu de souci pour restaurer... et dieu sait si base de données et industrie pharma c'est important !!

cependant juste une chose, avoir une base de données critiques sans avoir de DBA, le tout dans le monde pro ça fait juste amateur !!

Il faut pas rever très peu de SI on un DBA.
Soit ils payent les services d'un DBA de temps en temps.
Soit il font comme nous et reste sur des techno maitrisées ( dump par exemple.)
tout réside dans les tests de restauration

[Bosquetia]

Ben on doit pas travailler dans les même boites... depuis 95 j'ai toujours eu un DBA dans mes équipes !

[bartounet]

c'est sur..
je suis aussi dans l"info depuis un bout de temps et que se soit mes boites et nos éditeurs, y a quasiment jamais de DBA

[i-magin]

Suite à ma migration ESXi 6.0 vers ESXi 6.5 Update 2, j'avais téléchargé ICI le dernier script "ghettoVCB.sh" (l'ancien script rejetait la version 6.5 lors du contrôle de version ESXi)
Concernant la date de version de "ghettoVCB.sh", j'ai trouvé cette mention : LAST_MODIFIED_DATE=2017_12_09

J'ai lancé une sauvegarde avec un snapshot présent et j'obtiens ce message : "2018-11-04 15:00:46 -- info: Snapshot found for jeedom_debian9, backup will not take place"

@Bosquetia, est-ce que l'on peut espérer retrouver ton tuto, STP ? Merci !

[benj29]

Hello, pour revenir au sujet .

Je me rends compte que lors de mon arrêt de Vm, j'ai une erreur sur le démontage sur /tmp/jeedom



Mais qu'en fait, il a déjà démonté /tmp/jeedom, voir plus haut.

Suis-je le seul ?

[anto35]

En fait non il l'a pas demonté.

Il l'affiche comme ça parce qu'il traite les taches en //.

Si il n'arrive pas à demonter, c'est qu'il doit toujours être en cours d'utilisation.

Envoyé de mon SM-G930F en utilisant Tapatalk

[benj29]

Le sujet c'est surtout faut-il s'inquiéter ?

[anto35]

De prime abord, oui ça m'inquieterait et je chercheraiq à savoir ce qui coince.

Ça peut être juste un fichier non fermé par Jeedom, comme un fichier en cours d'écriture. Et c'est pas du tout pareil.

T'as essayé d'arrêter Jeedom avant la VM ?

Envoyé de mon SM-G930F en utilisant Tapatalk

[Bosquetia]

c'est d'ailleurs la meilleure chose a faire arrêter jeedom !

[benj29]

Hurmf, subtilité bien vu !

[benj29]

Je me réponds à moi même pour la sauvegarde auto

[benj29]

Bon, mine de rien c'est pas si évident que ça.
Heureusement en ce moment, j'ai beaucoup de temps pour moi (enfin...).
Donc j'ai pu faire tout ça.

Je ne suis pas un DBA ou un admin info, mais j'ai un peu de bouteille éloignée la bouteille pour Linux.
Au final :

- Proxmox installé sur un SSD 300 Go en suivant les recommandations de nibbs/joe (bon je n'ai qu'un regret, ne pas avoir mis en place un raid logiciel pour l'OS, j'aurai été plus tranquille) ;
- Ajout du QNAP en backup pour les VM ;
- Ajout d'un second administrateur ;
- Activation de la surveillance SMART du disque ;
- Ajout de fail2ban bien configuré ;
- Mise en place du HTTPS ;
- Mise en place d'un DYNDNS pour OVH ;
- Ajout de la notification par email sur mon gmail perso ;
- Ajout de la gestion de l'onduleur global via nut-client ;
- Création des VM :
* Jeedom OK et tourne depuis samedi,
* BLEA SENA en Debian 9 (car 2 CPU sur Jeedom),
* PLEX,
* MotionEye
* La base debian9 pour le serveur SNIPS est là mais ce sera pour plus tard.

J'en ai profité pour :
- mettre en place openvpn sur mon asus,
- mettre en place le wol en cas d'arrêt global,
- tester l'arrêt total de l'installation en cas de coupure longue.



Tout ce petit monde est surveillé dans Jeedom mais aussi via JPI en externe (en cas d'arrêt Proxmox ou du NAS).





Merci à tous pour votre aide. J'arrive au bout de ce fil pour ma part.
Je pourrais toujours en sortir un tuto, mais là il faudra que je copie colle mes notes et que je vire tout le perso...

A tout hasard, peut-on migrer d'un seul disque 300 Go si j'achète un m2sata de même taille par exemple vers un RAID logiciel sans tout se retaper ?

[Jeandhom]

Le raid1 logiciel sous mdadm peut être fait après.
Le disque neuf est configuré en raid1 avec 1 disque manquant (degraded).
L'OS est copié depuis le disque d'origine vers le raid1.
Le boot est fait à partir du raid1.
Le disque d'origine est reformaté pour être ajouté au raid1.