Backup restore issues (OVH SBG issues)

:uk:
VPS SBG2 OVH 4.1.7.3
Hi everyones,

Did you hear from OVH datacenter SBG news? Because I’ve one of my VPS over there. Too bad to see all these data goind into the cloud…
So i’ve tried to restore my one month old full backup to a new server and having some issues with all the data, users and apps.

I’ve performed command line install / uploaded tar files via scp / moving and restoring the archive.
All process went well but unfortunately after login into the admin panel, all domains(3), app (3) and users (50) are gone.

After somme research it appear that :

  • all app are not installed in yunohost.app
  • users are still here in /home
  • domains too in /ect/nginx/conf.d
  • mail ok in var/mail

So I can’t create missing domain because they’re still présent on the server but not visible in the admin panel.

Is there a way to restores users and domain?

:fr:
VPS SBG2 OVH 4.1.7.3
Salut tout le monde,

Avez-vous eu des nouvelles du centre de données OVH SBG? Parce que j’ai un de mes VPS là-bas. Dommage de voir toutes ces données aller dans le cloud …
J’ai donc essayé de restaurer ma sauvegarde complète d’un mois sur un nouveau serveur et j’ai eu des problèmes avec toutes les données, les utilisateurs et les applications.

J’ai effectué l’installation / téléchargement de fichiers tar en ligne de commande via scp / déplacement et restauration de l’archive.
Tout le processus s’est bien passé, mais malheureusement, après la connexion au panneau d’administration, tous les domaines (3), l’application (3) et les utilisateurs (50) ont disparu.

Après des recherches sommaires, il semble que:

  • toutes les applications ne sont pas installées dans yunohost.app
  • les utilisateurs sont toujours là dans / home
  • domaines aussi dans /ect/nginx/conf.d
  • mail ok dans var / mail

Je ne peux donc pas créer de domaine manquant car ils sont toujours présents sur le serveur mais non visibles dans le panneau d’administration.

Existe-t-il un moyen de restaurer les utilisateurs et le domaine?

1 Like

J’ai créé l’utilisateur principal (moi) et le service mail fonctionne en émission et reception.

Les mails restaurés sont toujours sur le serveur, par contre les mails qui datent d’aprés le backup ne le sont pas. Ils sont toutefois présent sur le client. C’est le principal.

Je pense re-créer tout les utilisateurs uns a uns.

Par contre au sujet des domaines je coince un peu.

Quand je tente d’ajouter un domaine qui était existant avant la restoration ca me rend cela :
https://paste.yunohost.org/raw/zurelokosu

en ligne de commande
yunohost remove cloud.maindomain.tld
me donne
Error: Domain ‘cloud.maindomain.tld’ unknown

alors qu’il est toujours présent dans /etc/nginx/conf.d

Mouarf ben ouai c’est un des soucis du système de backup actuel …j’ai justement fait une PR à ce sujet tout à l’heure : Don't backup stuff that ain't relevant for backup by alexAubin · Pull Request #1185 · YunoHost/yunohost · GitHub

TL;DR : supprimes les conf nginx correspondantes …

3 Likes

j’ai bien supprimé les fichiers .conf

faut-il faire une autre actions? recharger un truc dnsmasq ou autre? Je cherche

ce que j’ai fait

  • Supprimer les fichiers *.conf en trop dans /etc/ningx/conf.d
  • yunohost tools regen-conf --dry-run --force que tu avait mit dans ce post
  • j’ai aussi fait service nginx restart et service dnsmasq restart
  • un redémararge.

Pour l’instant cela ne me permet toujours pas de créér les anciens noms de domaine.

T’as des log de l’opération d’ajout du domaine ?

Si tu as restauré l’archive quel était le bilan de la restauration (il y a un bilan partie par partie de système) ?

Là si ton ton domaine n’est pa spris en compte, ça donne l’impression que la restauration de conf_ldap n’a pas fonctionné.

Tu peux essayer de restaurer ce point spécifiquement:

yunohost backup restore ARCHIVE --system conf_ldap 

Vérifie aussi que ton disque n’est pas plein (à tout hasard) et l’état de slapd:

df -h
systemctl status slapd

Est ce que tu as procédé à la restauration avec ou sans post-install ?

sans post-install et df -h donne 62% de libre

je vais essayer de restaurer que le conf_ldap

systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
Loaded: loaded (/etc/init.d/slapd; generated)
Drop-In: /etc/systemd/system/slapd.service.d
└─ynh-override.conf
Active: active (running) since Thu 2021-03-11 10:54:26 UTC; 56min ago
Docs: man:systemd-sysv-generator(8)
Process: 795 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
Tasks: 8 (limit: 4915)
Memory: 28.1M
CGroup: /system.slice/slapd.service
└─922 /usr/sbin/slapd -h ldap://127.0.0.1:389/ ldaps:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Bonjour @Acidope, je vois qu’on est au moins deux dans la panade avec cette histoire d’OVH.
Je suis désolé, je n’ai pas le niveau technique pour pouvoir t’aider efficacement. J’espère que tu pourras remonter ton serveur au plus vite.

La gestion de crise semble pour le moins douteuse : pas un seul email, pas une seule communication depuis quasiment 48h à part deux ou trois tweets laconiques du fondateur. Le fait que ce datacenter puisse partir en flammes comme ça donne honnêtement de sérieux doutes sur le professionnalisme de l’équipe !

Tu avais tes backup chez OVH ou ailleurs ? Ça m’intéresserait de savoir !
De mon côté mes deux instances étaient automatiquement sauvegardées deux fois par semaine, mais impossible d’avoir accès à mes sauvegarddes depuis l’interface client ! Incroyable, payer des sauvegardes pour ne pas les retrouver au moment où on en a besoin…

Je n’ai pas perdu de données, et normalement mes instances étaient sur SBG3 qui est coupé mais non endommagé (mais peut-on se fier à la com’ OVH ?). Si j’en crois le seul tweet que cette entreprise a bien daigné offrir à ses clients, je vais devoir patienter au moins jusqu’au 19 mars. En attendant, mode bricolage avec une redirection MX sur mes DNS vers les serveurs email d’OVH.

Enfin, j’avoue ne pas savoir si ma demande est compatible avec les règles du forum, mais que les modérateurs ne se privent pas pour supprimer ce paragraphe le cas échéant : auriez-vous des conseils d’hébergeurs VPS, si possible en France ? J’avais passé l’éponge à OVH après la grosse panne en 2017, mais là je crois que c’est la fois de trop !

yunohost backup restore 20210131-204714 --system conf_ldap
Warning: YunoHost is already installed
Do you really want to restore an already installed system? [y/N]: y
Info: Preparing archive for restoration…
Warning: cp: cannot stat ‘/home/yunohost.backup/tmp/20210131-204714/conf/ldap/slapd.conf’: No such file or directory
Warning: 604a067d Entry (cn=mail.main,ou=permission,dc=yunohost,dc=org): object class ‘permissionYnh’ requires attribute ‘authHeader’
Warning: slapadd: dn=“cn=mail.main,ou=permission,dc=yunohost,dc=org” (line=2715): (65) object class ‘permissionYnh’ requires attribute ‘authHeader’
Warning: Unable to restore LDAP database
Error: Could not run script: /usr/share/yunohost/hooks/restore/05-conf_ldap
Error: Could not restore the ‘conf_ldap’ system part
Info: The operation ‘Restore system from a backup archive’ could not be completed. Please share the full log of this operation using the command ‘yunohost log display 20210311-120059-backup_restore_system --share’ to get help
Success! Configuration updated for ‘dnsmasq’
Warning: The configuration file ‘/etc/ssh/sshd_config’ has been manually modified and will not be updated
Error: Nothing was restored

https://paste.yunohost.org/raw/geriwivava

Par ailleurs j’ai déjà commencé a recréér manuellement les utilisateurs. J’espère que ca ne viendras pas mettre la pagaille :grimacing:

Malheureusement les VPS c’est galère. Scaleway n’a pas eu trop de soucis je crois depuis le début.
Évite les VPS Firstheberg moi ils m’en on flingué 2, ça ressemblait à une grappe raid corrompue (en tout cas le stockage n’était pas fiable).

Tu peux aussi venir chez un fournisseur associatif comme ARN FAI, mais bon si tu cherches une grosse fiabilité, se baser sur des bénévoles n’est pas l’idéal, à moins de t’investir dans l’équipe d’adminsys (ce qui permet de dépanner ses propres soucis et d’avoir un contrôle de comment c’est fait).

Les snapshot ne sont pas des backups, je conseille à tous le monde d’essayer de gérer au moins un backup soit même (quitte à laisser l’autre backup au snapshot OVH).

1 Like

je ne suis pas au point sur tout les produit d’OVH mais peut importe chez qui tu vas. Les backup c’est toujours sur 3 points. Local et deux distants.

Pour ma part j’avais un local mais un peu vieux (30j).
Au sujet des avancements OVH va sur ce lien c’est maj plus souvent.

http://travaux.ovh.net/?do=details&id=49484

Bon courage

@Acidope tu devrais essayer en faisant la postinstall avant.

Je suppose que c’est une restauration de YunoHost 3.8 vers 4.1.x ?

Ah… possible l’archive date du 31 janvier… la 4.0 date du 26 janvier et je ne suis pas sur d’avoir upgrader.

par contre le serveur est repartis en production, je peut pas les couper a nouveau.
J’aimerais trouver une solution pour reconstruire les domaines manuellement.

Bonsoir,

Restauration en cours de mon côté aussi. J’ai restauré une sauvegarde de la semaine dernière sur une installation fraîche en 4.1.7.4. Je pense que mon serveur était en 4.1.7.

Tout semble ok après la restauration. J’ai juste vu passer le message suivant également:

Warning: cp: cannot stat '/home/yunohost.backup/tmp/goodway-20210305/conf/ldap/slapd.conf': No such file or directory

Bonjour, merci pour vos réponses !

Ils sont quand même un peu présentés comme tels sur le site d’OVH, non ?

C’est vrai, j’ai un peu péché par confiance. J’avais bien mes deux points distants, mais au même endroit. Pour ce qui est du backup local, je comptais sur une “Time Machine” en lien avec mon ordinateur principal. Ce qui fonctionne parfaitement, mais uniquement pour les données Nextcloud (c’est le principal !). Je risque de voir perdues quelques données annexes, notamment un bel historique de plusieurs années Wallabag… Ça me servira de leçon.

D’ailleurs à propos de leçon, comment faites-vous votre sauvegarde locale ? Téléchargement manuel ?

Sinon je suis désolé mais je continue un peu dans le hors sujet, si jamais certains savent répondre.
Je trouve la communication d’OVH absolument nulle sur le sujet, et je n’arrive pas à bien comprendre l’étendue des dégâts.

  • Sur mes factures, mes VPS apparaissent comme étant sous la rubrique “Public Cloud”, dans la “région sbg3”. Dans leur FAQ en ligne, ils parlent de deux choses distinctes que sont le datacenter SBG3 d’une part (non affecté), et l’openstack-sbg3, physiquement dans le datacenter SBG2, donc complètement détruit par l’incendie. Dois-je en déduire que mon VPS était dans le datacenter SBG2 ou SBG3 ?
  • Tous mes VPS étaient automatiquement backupés (snapshots et sauvegardes disques) chez OVH, mais sait-on où étaient physiquement mis ces snapshots par OVH ? Dans le même dataceneter exactement ? Ils parlent de triple réplication, les trois répliques étaient au même endroit ?

Ça paraît assez fou…

Merci pour votre aide en tout cas.

Je n’avais pas mis le résultat complet :grimacing:

systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /etc/systemd/system/slapd.service.d
           └─ynh-override.conf
   Active: active (running) since Thu 2021-03-11 12:01:01 UTC; 8h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2508 ExecStart=/etc/init.d/slapd start (code=exited, status=0/SUCCESS)
    Tasks: 8 (limit: 4915)
   Memory: 20.9M
   CGroup: /system.slice/slapd.service
           └─2515 /usr/sbin/slapd -h ldap://127.0.0.1:389/ ldaps:/// ldapi:/// -g openldap -u openldap -F /etc/ldap/slapd.d

Mar 11 18:09:59 maindomain.tld slapd[2515]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
Mar 11 18:10:04 maindomain.tld slapd[2515]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
Mar 11 18:10:12 maindomain.tld slapd[2515]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
Mar 11 19:34:16 maindomain.tld slapd[2515]: connection_input: conn=1189 deferring operation: binding
Mar 11 19:40:56 maindomain.tld slapd[2515]: connection_input: conn=1192 deferring operation: binding
Mar 11 19:42:07 maindomain.tld slapd[2515]: connection_input: conn=1192 deferring operation: binding
Mar 11 19:42:14 maindomain.tld slapd[2515]: connection_input: conn=1192 deferring operation: binding
Mar 11 19:58:58 maindomain.tld slapd[2515]: connection_input: conn=1198 deferring operation: binding
Mar 11 20:02:09 maindomain.tld slapd[2515]: connection_input: conn=1198 deferring operation: binding
Mar 11 20:19:05 maindomain.tld slapd[2515]: connection_input: conn=1206 deferring operation: binding

J’ai le même message. As-tu plusieurs domaine sur ton instance et sont-ils présent aprés restauration ou bien encore as-tu pus les re-créér? le même nombre d’utilisateurs qu’avant?

Moi je croive qu’ils en sachent pas la totalité :slight_smile: et qu’ils nous tiennent aux courant des avancées aux fur et à mesures qu’ils découvrent les problèmes. Ils subissent un cas assez grave, mettent en place des procédures d’urgence, restent transparent sur leur avancée. Je trouve que les news sont assez claires :

  • SBG2 doit être presque entièrement reconstruit.
  • SBG1 a été lourdement endommagé.
  • Salle de réseau SBG1 - Salle conservée à la suite de la vérification préliminaire ETA : début de la semaine prochaine)
  • ETA provisoire pour électrique = lundi 15 mars
  • Les jours suivants, les serveurs seront activés pièce par pièce après audit
  • Pour SBG4 : les vérifications préliminaires et ne révèlent aucun problème. L’objectif est maintenant de rétablir l’électricité en semaine 12 et de rétablir progressivement tous les services.
    • SBG3 non touché par l’incendie. L’objectif est de rétablir le courant et le réseau semaine 12 et de restaurer progressivement tous les services

Qu’est ce que tu as dans ton manager?

Capture d’écran 2021-03-12 à 08.54.08

J’ai un autre serveur sur SBG3, je ne pense pas qu’il serat dispo lundi matin 8h mais j’ai espoir de recup le peu de données qu’il me manque.

Quand meme content de ne pas avoir placé toutes mes billes sur SBG. Je vais dorénavant faire un backup des 3 serveur sur un RPI en local. C’est dommage de l’apprendre par la force des choses tout de même.

1 Like