DFSR разработана для использования для Аварийного восстановления?
Мы в настоящее время работаем над реализацией стратегии DR. Вместо репликации SAN-SAN было решено иметь 2 живых тиражирования файловых серверов через DFSR. Однако я не знаю, является ли это хорошей идеей.
Пример: DFS не копирует заблокированные файлы. Скажем, у пользователя есть электронная таблица, открытая в течение многих недель. Они действительно периодически сохраняют, но файл все еще остается открытым. Затем активный файловый сервер понижается, и пользователи перенаправляются к другому серверу, где файл не копировался.
Существует ли способ смягчить тот сценарий? Я неправильно понимаю что-то? Или РАЗВЕ DFSR не разработан, чтобы быть технологией DR?
Править: Что другие дефициты DFSR имеет в контексте DR кроме моего примера выше?
Я только что отошел от среды DFS-R по той самой причине, которую вы описали выше. Заблокированные файлы невозможно обработать и вызывает всевозможные конфликты, особенно если оба сервера используются как правильный обход отказа (поэтому пользователи бьют по обоим серверам одновременно).
Для меня DFS-R пригодится для репликации через WAN/VPN соединения в удаленные офисы, а не в качестве DR-решения. Я настоятельно рекомендую получить какое-то общее хранилище и использовать кластеры обхода отказа, которые значительно улучшились в 2012 R2 (я все еще работаю с 2008 R2, но пока что это нам очень помогло)
.Он не предназначен для DR. Не таким образом - в данном случае проблема в пользователе. Я не уверен, что что-нибудь справится с этим хорошо.
DR также является паршивым сценарием, он с радостью реплицирует вирус, шифрующий ваши файлы (или удаляющий их).
.Да и нет, сохраняйте задержку между синхронизациями, чтобы не синхронизировать стирание или повреждение. Это только хороший способ сохранить файл, который вы не хотите потерять, но это минимальный сценарий "резервного копирования".
Я бы разместил этот сервер в другом месте и на локальном хранилище. (так как я не знаю вашу топологию SAN)