Вопросы Теги

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

На этот вопрос уже есть ответ здесь:

Редактировать: a Последующий вопрос: Восстановите mongoDB с помощью --repair и WiredTiger .

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

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

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

GRUB

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

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

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

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

9
задан 25 March 2019 в 15:37
3 ответа

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

3
ответ дан 2 December 2019 в 22:18

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

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

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

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

7
ответ дан 2 December 2019 в 22:18

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

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

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

* Особая форма бэш-оператора 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
36
ответ дан 2 December 2019 в 22:18

Теги

Похожие вопросы