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
:
#!/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:
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!
/data/
;/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.
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
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.
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.