RAID-1 и обычное удаление диска (с использованием RAID-1 в качестве меры резервного копирования)

Я бы сказал, что это не очень хорошая идея. Все, от чего вы защищаете в большинстве случаев - это проблемы с физическим / электрическим приводом, и у вас есть только одна копия резервной копии, которая очень уязвима при обновлении.

Если ошибка возникает на другом диске или на вашей машине в целом, во время повторной синхронизации вы можете остаться без основного диска, а диск «bakcup» имеет частично обновленную (то есть потенциально очень поврежденную) файловую систему. Это одна из причин, по которой большинство решений для резервного копирования включают несколько резервных копий (еще одна ключевая причина заключается в том, что вы можете иметь по крайней мере одну резервную копию в автономном режиме (и предпочтительно автономную) при обновлении другой), но усугубляется тем, что повторная синхронизация RAID выполняется не будет осведомлен о файловой системе, поэтому не сможет ничего сделать, чтобы частичная повторная синхронизация оставила файловую систему в состоянии, близком к согласованному (например, она может синхронизировать записанные данные перед связанными блоками журнала и т. д.).

Если вы выполняете RAID-настройку всей своей системы таким образом, то снижение производительности записи с намерением записи также может быть весьма значительным (см. Сообщения типа http://blog.ganneff.de/blog/2008/01/30/write-intent-bitmaps. -considere.html ), хотя, если вы используете только файловые системы RAID, которые не видят большой активности записи, это может вас не беспокоить.

Если вы используете эту технику, убедитесь, что вы запустились, syncпрежде чем принудительно извлекать диск.

Вы рассматривали возможность использования rsync для обновления резервной файловой системы? Это было бы медленнее в ваших решениях в лучшем случае (поскольку требуется полная проверка размеров файлов и дат, даже если ничего не изменилось, что может быть важно, если файловая система содержит много файлов), но обычно это достаточно быстро и, безусловно, будет быстрее, чем полная повторная синхронизация, где драйвер RAID, чтобы решить это необходимо.

Похоже, идея массива RAID-1 на основе external_HDD работает.

Массив начинает ухудшаться и отслеживает изменения, используя растровое изображение с намерением записи.

Когда я подключаю свой внешний жесткий диск, мой udevскрипт обнаруживает, что один из разделов подходит моему массиву, и добавляет его. Он синхронизируется (мгновенно, если не было никаких изменений), а затем действует как ускорение доступа для чтения.

Когда я отсоединяю свой внешний жесткий диск (включая внезапное удаление), другой udevсценарий регистрирует, что диск удален, и массив снова становится поврежденным.

Однако наблюдается заметное снижение производительности записи, но оно приемлемо для этого использования.

Другое преимущество заключается в том, что я могу временно отформатировать этот раздел для какого-либо другого использования, а затем вернуть его в массив (с полной перестройкой).

В этом я вижу одну проблему: файловая система на удаленном внешнем жестком диске может находиться в состоянии, которое невозможно смонтировать, хотя современные файловые системы с журналированием и т. Д. Снижают этот риск.

Но если вы используете mdadm, я могу предположить, что вы используете какой-то вариант Linux и рекомендовал бы вместо этого использовать rsync. Это будет быстро, так как будут скопированы только измененные файлы, и это также позволит вам иметь скрипт, который создает папку с текущей датой на внешнем жестком диске, а затем создает полную резервную копию вашего внутреннего жесткого диска под ним, но жестко связывает файлы с предыдущая резервная копия, таким образом, используя пространство только для новых данных. Таким образом, вы можете легко восстановить файл, который мог быть удален на внутреннем жестком диске.