Question J'ai accidentellement compressé tout mon serveur


Bien si quelqu'un veut jouer à Dieu et faire des miracles, je suis en bas.

Donc, on m'a confié la tâche de créer un script qui trouvait les fichiers de plus de 6 mois, les compressait, puis les supprimait. En écrivant ce script, j’ai lancé ceci:

find / -type f -mtime -400 ! -mtime -180 | xargs gzip blablabla

Et cela donnait à CHAQUE FICHIER UNIQUE une extension .gz. Maintenant, je l'ai défait dès que j'ai remarqué mais c'était un peu trop tard. À la fin de la commande, aucune de mes commandes bash ne fonctionnerait car la variable $ PATH se vide elle-même. J'ai essayé beaucoup de choses avant de réaliser quel était le problème.

Donc, après avoir décompressé tout ce que je suis toujours incapable de démarrer. J'ai réussi à me rendre au secours, après quoi j'ai suivi les instructions en ligne pour:

root (hd0,0)
setup (hd0)
kernel (hd0,0)/boot/vml[...]
initrd (hd0,0)/boot/initrd.im[...]

Après quoi mon linux démarre partiellement mais me donne les erreurs suivantes:

Begin : Running /scripts/init-bottom ... mount : mounting /dev on /root/dev failed : No such file or directory
mount: mounting /sys/ on /root/sys failed: No such file or directory
mount: mounting /proc on /root/proc failed : No such file or directory
Target filesystem doesn't have requrested /sbin/init.
No init found. Try passing init= bootarg.

J'ai essayé de réparer le système de fichiers, j'ai démarré à partir de 3 disques LiveCD / Rescue différents, j'ai exécuté la réparation de démarrage à partir de 2 disques différents. J'ai forcé des fscks ...

Je suis vraiment à court d'idées et j'ai BESOIN d'obtenir que ce serveur démarre au moins pour pouvoir récupérer mes bases de données SQL. Je cherche désespérément de l'aide, je paierai même si besoin est.

Cela fait 3 jours que je guette sur des forums toute la journée pour trouver une solution et je suis toujours au même point ... Aide s'il vous plaît?


11
2017-10-15 19:52


origine


si ce sont des bases de données mysql, vous n'avez pas nécessairement besoin de démarrer; dans ce cas, j'essaierais de monter le lecteur en tant qu'esclave et de copier le répertoire / var / lib / mysql - user16081-JoeT
Installation propre sur les nouveaux périphériques de stockage. Montez l'ancien disque, transférez les données selon vos besoins. Je parierais que la réparation ne vaudra pas la peine. - Zoredache
C'est le point où vous restaurez à partir d'une sauvegarde. Et souvenez-vous de ne pas courir plus tard en effectuant des actions non privilégiées en tant qu'utilisateur root. - Magellan
because of version differences, ré-installer avec la même version exacte. we have corruption issues, vos données peuvent être corrompues. Réparer le système pour qu'il soit amorçable ne vous aidera pas si les données ont été supprimées. Si votre commande gzip a compressé vos fichiers de base de données alors que la base de données était utilisée, la corruption semble inévitable. - Zoredache
Si votre logiciel de base de données était en cours d'exécution pendant l'exécution de ces commandes, vous ne pourrez peut-être pas récupérer les bases de données. Gzip aurait volontiers compressé le fichier, puis l'a dissocié. Mais le logiciel de votre base de données avait toujours le fichier ouvert et il enregistrait les modifications. Dès qu'il s'est arrêté, le fichier a ensuite été supprimé. - toppledwagon


Réponses:


Cela dépend si les systèmes de fichiers sont suffisamment réparés pour que vous puissiez monter ces partitions à partir d'un LiveCD. Ne cherchez pas encore à démarrer le système. Commencez par monter les partitions et décompressez tous les fichiers .gz. Cela vous donnera des copies de travail des binaires init et système. Ensuite, vous pouvez utiliser grub pour réparer le secteur de démarrage. Ensuite, démarrez en mode mono-utilisateur et fsck à nouveau le système de fichiers. Si cela fonctionne, vous aurez un système en cours d'exécution. Vous aurez également un tas de fichiers décompressés (tels que des pages de manuel) qui devraient vraiment être compressés, mais c'est mieux que d'avoir un système non amorçable.

Si vous ne pouvez pas monter les partitions à partir d’un LiveCD, vous n’avez malheureusement pas de chance. Rien ne pourra récupérer votre système à ce stade.


8
2017-10-16 00:19



Cela a réellement fonctionné comme un charme ... je ne peux pas vous remercier assez pour cela! MySQL ne voulait pas démarrer, mais je n'ai pas encore fait le fichier --force fsck, j'espère que ça va le réparer! MERCI - Dexirian
Impressionnant. Content que ça ait aidé. - Michael Martinez


La première chose que je voudrais essayer est d’exécuter un environnement LiveCD et d’essayer de tout décompresser, en espérant que cela ramènerait le système à un état amorçable. Remarque: je crains que les données ne soient corrompues si le processus gzip d'origine était interrompu.

Sinon, j'essaierais de migrer la base de données vers un nouveau système, comme le suggèrent d'autres personnes, mais il est possible que vous rencontriez des problèmes de dépendance et de configuration exigeants en main-d'œuvre qui devront être résolus individuellement.


9
2017-10-15 20:11



Question rapide: Nous ne sommes pas sûrs de l'ancien serveur de base de données SQL et le serveur le plus récent utilise un Distro Linux différent. Le serveur le plus récent exécute CentOS avec WHM et l’ancien serveur était soit Debian / Unbuntu. Ma question est donc la suivante: comment puis-je migrer efficacement mes bases de données SQL sans corruption et quoi? - Dexirian


Le consensus général ici, selon lequel vous devez simplement monter le disque dans un système en fonctionnement et récupérer vos fichiers, n’est pas faux. C'est la chose sensée à faire. Mais l’autre solution est plus amusante et très éducative. J'ai beaucoup appris en luttant pour sortir de situations désordonnées où d'autres personnes auraient tout simplement abandonné et réinstallé à partir de zéro. (Pas sur un serveur que d'autres personnes dépendent cependant ...)

Quoi qu'il en soit, jusqu'à présent, vous avez un initramfs (initrd) qui s'exécute. C'est un bon début. Mais il ne peut pas terminer le transfert à init car init est maintenant init.gzpeut être? Pour progresser, il serait utile de savoir exactement quelle est la distribution Linux que vous avez, afin que nous puissions rechercher quels outils sont disponibles dans ses initramfs pour une utilisation en urgence.

Les messages d'erreur que vous avez présentés semblent provenir des initramfs de Debian. Si c’est Debian, alors vous devriez avoir un (initramfs) invite du shell sur la ligne suivante après la dernière erreur. Si vous le faisiez, vous devriez regarder ce qui se passe avec ces montures ratées. est /root/dev manquant? (/root est l'endroit où votre fs root normal doit être monté lors de l'exécution de initramfs)

Si vous n'avez pas reçu l'invite du shell, que s'est-il passé après? No init found. Try passing init= bootarg. sera intéressant. Même si ce n'était qu'un curseur clignotant, c'est un indice. S'il semble totalement gelé, essayez d'obtenir des informations sur les processus en cours à l'aide de Magic sysrq ou de Ctrl + ScrollLock.

La initramfs de Debian vous permet également de demander un shell à quelques points de repère spéciaux en ajoutant un break= paramètre sur la ligne de commande du noyau. Par exemple, pour obtenir un shell avant la Running /scripts/init-bottom ligne, utilisation break=bottom.

A part: je ne sais pas comment find commande aurait pu être gzippé chaque fichier ... cela me semble correct dans le but de sélectionner des fichiers entre 180 et 400 jours.


6
2017-10-16 00:35



Quand je fais un ls sous / root il n'y a rien trouvé. Donc, je peux le supporter, le montage en FS n’est pas correct au démarrage? Où puis-je le changer? - Dexirian
@Dexirian, vous avez donc reçu une invite du shell (devez-vous utiliser break=bottom?) ... oui, au moment où il essaie de monter /root/dev et /root/proc et /root/sys, /root devrait être le vrai système de fichiers racine. Il doit y avoir eu un message d'erreur plus tôt, à propos de l'échec de le monter. Avez-vous inclus un root= paramètre dans la ligne de commande du noyau? Ma mémoire est un peu floue sur ce point mais je pense que le root (hd0,0) indique simplement à grub où trouver ses fichiers de support, et vous devez toujours indiquer séparément au noyau où se trouve la racine. - Wumpus Q. Wumbley
Oui, j'ai utilisé root =, kernel = initrd =, et setup =, je n'ai pas eu à utiliser break = bottom. Et je n'ai pas repéré un message de montage précédemment échoué, car il défile très rapidement - Dexirian
@Dexirian Est-ce que le scrollback de la console est disponible? Maj + PgUp. Et pouvez-vous le monter depuis (initramfs)  rapide, quelque chose comme mount -r /dev/sda1 /root? cat /proc/partitions pour voir quels disques sont disponibles. - Wumpus Q. Wumbley
Bienvenue dans le monde de l'administration système. - Michael Martinez