Горячее резервное копирование MongoDb - копирование данных / db VS replicaset с помощью fsyncLock

Я читал о различных настройках MongoDB для резервного копирования без простоев. Какая стратегия лучше или их можно даже сравнить?

1. Включите ведение журнала и просто скопируйте каталог / data / db - мне неясно, достаточно ли этого - на домашней странице MongoDB указано, что вам нужно сделать "снимок", и он работает в SAN и LVM в качестве примеров.

   Вопросы:

   Что в данном контексте означает «снимок», будет ли команда копирования считаться снимком? Сохраняется ли копирование журнального каталога данных MongoDB (2.0+) на сервер Windows с NTFS? Как вы гарантируете, что это безопасно делать с вашей собственной файловой системой и настройкой?

2. Установите набор реплик с 2 серверами и арбитром. Затем используйте rs.status () и fsyncLock / unlock, чтобы обеспечить чтение данных только на вторичном сервере во время резервного копирования.

   > db.fsyncLock
   function () {
   return db.adminCommand ({fsync: 1, lock: true});
   }
   > db.fsyncUnlock
   function () {
   вернуть db.getSiblingDB ("админ"). $ cmd.sys.unlock.findOne ();
   }
   

   Вопросы:

   Если вы используете блокировки в наборе реплик, кажется, что запись и чтение могут быть заблокированы для всего набора реплик, и эта ошибка не исправлена?

   Что, если ошибка вторичный считается основным, пока выполняется резервное копирование? Остановится ли процесс резервного копирования или набор реплик перестанет отвечать на запросы записи, пока он не будет разблокирован?

   Соображения:

   На данный момент мне нужно простое решение и просто скопировать данные / ] db каталог с файлами журнала и дождитесь набора реплик. MongoDB работает на 64-битном сервере Windows (RackSpace Cloud).