Назад | Перейти на главную страницу

База данных случайно удалена с помощью сценария bash

Изменить: дополнительный вопрос: Восстановите mongoDB с помощью --repair и WiredTiger.

Мой разработчик совершил огромную ошибку, и мы не можем найти нашу базу данных Mongo на сервере.

Он вошел на сервер и сохранил следующую оболочку под ~/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天前的旧备

А затем он запустил его, и он вывел permission denied сообщения, поэтому он нажал Ctrl+C. Сервер выключился автоматически. Он попытался перезапустить его, но получил ошибку grub:

Он связался с AliCloud, инженер подключил диск к другому рабочему серверу, чтобы он мог проверить диск. Похоже, некоторые папки исчезли, в том числе /data/ где mongodb!

  1. Мы не понимаем, как скрипт мог уничтожить диск, в том числе /data/;
  2. И, конечно, возможно ли получить /data/ назад?

PS: Снимок диска раньше не делал.

PS2: Поскольку люди часто упоминают «резервные копии», у нас есть много важных пользователей и данных, поступающих в эти 2 дня, целью этого действия было их резервное копирование (в первый раз), затем они оказались полностью удалены.

Достаточно просто. В // последовательность не является комментарием в bash (# является).

Заявление OUT_DIR=x // text не оказало никакого эффекта *, кроме загадочного сообщения об ошибке.

Таким образом, поскольку OUT_DIR является пустой строкой, одна из выполненных команд в конечном итоге была rm -rf /*. Некоторые каталоги размещены непосредственно под / не были удалены из-за отсутствия у пользователя прав, но похоже, что некоторые жизненно важные каталоги мы удалено. Вам нужно восстановить из резервной копии.

* Своеобразная форма оператора bash A=b c d e f примерно похож на:

export A=b
c d e f
unset A

Типичный пример: 

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 (!)

И проблемная строка сценария сводилась к следующему:

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

1) Он ошибочно предположил, что // был комментарий bash. Это не так, только # является.

Оболочка интерпретируется // text как обычная команда, и не нашел двоичный файл с именем //, и ничего не сделал.

В bash, когда у вас есть присвоение переменной (OUT_DIR=/data/backup/mongod/tmp) непосредственно перед командой (// text), он устанавливает переменную только во время выполнения команды. Следовательно, это сбрасывает OUT_DIR немедленно, а когда достигнута линия rm, OUT_DIR теперь не установлен, и rm -rf / теперь вызывается, удаляя все, что у вас есть разрешение на удаление.

2) Решение такое же, как и у всех rm -rf / случаи: восстановление из резервной копии. Другого решения нет, потому что у вас нет физического доступа к жесткому диску.

1) Комментарии Bash начинаются с символа #. Сожалею о вашей утрате. 2) Восстановление из резервной копии - это, к сожалению, единственный способ продолжить работу.