web-dev-qa-db-fra.com

Base de données supprimée accidentellement avec un script bash

Edit: une question de suivi: Restaurer mongoDB par --repair et WiredTiger .

Mon développeur a commis une énorme erreur et nous ne pouvons trouver notre base de données Mongo nulle part sur le serveur.

Il s'est connecté au serveur et a enregistré le shell suivant sous ~/crontab/mongod_back.sh:

mongod_back.sh

#!/bin/sh
DUMP=mongodump
OUT_DIR=/data/backup/mongod/tmp  // 备份文件临时目录
TAR_DIR=/data/backup/mongod      // 备份文件正式目录
DATE=`date +%Y_%m_%d_%H_%M_%S`   // 备份文件将以备份对间保存
DB_USER=Guitang                  // 数库操作员
DB_PASS=qq■■■■■■■■■■■■■■■■■■■■■  // 数掘库操作员密码
DAYS=14                          // 保留最新14天的份
TARBAK="mongod_bak_$DATE.tar.gz" // 备份文件命名格式
cd $OUT_DIR                      // 创建文件夹
rm -rf $OUT_DIR/*                // 清空临时目录
mkdir -p $OUT_DIR/$DATE          // 创建本次备份文件夹
$DUMP -d wecard -u $DB_USER -p $DB_PASS -o $OUT_DIR/$DATE  // 执行备份命令
tar -zcvf $TAR_DIR/$TAR_BAK $OUT_DIR/$DATE       // 将份文件打包放入正式
find $TAR_DIR/ -mtime +$DAYS -delete             // 除14天前的旧备

Et puis il l'a couru et il a sorti permission denied messages, alors il appuya sur Ctrl+C. Le serveur s'est arrêté automatiquement. Il a essayé de le redémarrer mais a eu une erreur de larve:

GRUB

Il a contacté AliCloud, l'ingénieur a connecté le disque à un autre serveur de travail afin qu'il puisse vérifier le disque. Il semble que certains dossiers aient disparu, notamment /data/ où est le mongodb!

  1. Nous ne comprenons pas comment le script pourrait détruire le disque, y compris /data/;
  2. Et bien sûr, est-il possible d'obtenir le /data/ retour?

PS: Il n'a pas pris d'instantané du disque auparavant.

PS2: Comme les gens parlent beaucoup de "sauvegardes", nous avons beaucoup d'utilisateurs et de données importants à venir ces 2 jours, le but de cette action était de les sauvegarder (pour la première fois), puis ils se sont avérés être entièrement supprimés.

9
SoftTimur

Assez facile. Le // la séquence n'est pas un commentaire dans bash (# est).

La déclaration OUT_DIR=x // text n'a eu aucun effet * sauf un message d'erreur cryptique.

Ainsi, avec OUT_DIR étant une chaîne vide, l'une des commandes finalement exécutées était rm -rf /*. Certains répertoires placés directement sous / n'ont pas été supprimés en raison de l'absence d'autorisations de l'utilisateur, mais il semble que certains répertoires essentiels étaient supprimés. Vous devez restaurer à partir d'une sauvegarde.


* La forme particulière de l'instruction bash A=b c d e f est à peu près similaire à:

export A=b
c d e f
unset A

Un exemple courant:

export VISUAL=vi                       # A standard visual editor to use is `vi`
visudo -f dummy_sudoers1               # Starts vi to edit a fake Sudo config. Type :q! to exit
VISUAL=nano visudo -f dummy_sudoers2   # Starts nano to edit a fake Sudo config
visudo -f dummy_sudoers3               # Starts vi again (!)

Et la ligne de script problématique se résumait à ceci:

export OUT_DIR=/data/backup/mongod/tmp
// 备份文件临时目录   # Shell error as `//` isn't an executable file!
unset OUT_DIR
36
kubanczyk

1) Il a supposé à tort que // était un commentaire bash. Ce n'est pas, seulement # est.

Le Shell a interprété // text comme commande normale, et n'a pas trouvé de binaire appelé //, et n'a rien fait.

En bash, lorsque vous avez une affectation de variable (OUT_DIR=/data/backup/mongod/tmp) précédant directement une commande (// text), il définit uniquement la variable lors de l'exécution de la commande. Par conséquent, il désactive OUT_DIR immédiatement, et lorsque la ligne rm est atteinte, OUT_DIR n'est plus défini et rm -rf / est maintenant appelé, supprimant tout ce que vous êtes autorisé à supprimer.

2) La solution est la même que toutes les rm -rf / cas: restauration à partir d'une sauvegarde. Il n'y a pas d'autre solution car vous n'avez pas d'accès physique au disque dur.

8
Ray Wu

1) Les commentaires basiques commencent par #. Désolé pour ta perte. 2) La restauration à partir d'une sauvegarde est malheureusement la seule façon de procéder ici.

4
RMPJ