1

Как мы можем быть уверены, что моментальный снимок только для чтения не поврежден из-за сбоя диска?

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

обоснование

Я регулярно создаю резервные копии своих снимков для предотвращения возможного сбоя диска. Несколько дней назад я не мог заставить btrfs send | btrfs receive за конкретный снимок. Когда я его удалил, остальные операции прошли как обычно. Более того, btrfs scrub сообщает, что есть несколько неисправимых ошибок. Это заставило меня подумать, что мои снимки на основном диске могут быть повреждены до того, как я скопировал их на внешний диск, и если я не буду знать об этом, я получу уже поврежденные резервные копии на внешнем диске.

Вот что я пытаюсь предотвратить. Я хочу быть уверен, что если я (могу) сделать резервную копию снимка, то он не будет поврежден.

1 ответ1

1

Есть два возможных ответа в зависимости от того, что вы подразумеваете под «поврежден из-за сбоя диска».

Если вы имеете в виду простое повреждение данных в покое

BTRFS обрабатывает это сам, прозрачно для пользователя. Он проверяет все, включая данные в снимках, внутри, а затем проверяет контрольные суммы при чтении каждого блока. Есть несколько исключений из этого:

  • Если том смонтирован с nodatasum или nodatacow , у вас не будет контрольной суммы блоков данных. В большинстве случаев вам не следует монтировать эти опции, поэтому это не должно вызывать проблем.
  • Любые файлы, для которых установлен атрибут NOCOW (C в выводе команды lsattr ), также не проверяются. У вас вряд ли будут какие-то действительно важные файлы с этим набором атрибутов (в файлах журнала systemd он установлен, но это все, если вы не установите его вручную).

Если вы имеете в виду нетривиальное уничтожение данных на томе из-за потери слишком большого количества устройств

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


Относительно вашего конкретного случая

Проблемы, о которых вы говорите при отправке / получении, вероятно, являются побочным эффектом тех неисправимых ошибок, о которых сообщает scrub. Когда BTRFS не может прозрачно исправить ошибку (обычно потому, что блок хранится с использованием профиля, который не может выполнить восстановление, например single или raid0), он возвращает ошибку ввода-вывода, что приведет к сбою операции отправки. Таким образом, у вас не будет уже поврежденных резервных копий, если вы используете отправку / получение (и на самом деле вы не будете использовать большинство других инструментов, любое хорошее программное обеспечение для резервного копирования выдаст ошибку, если не сможет прочитать файл ).

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

find . -exec cat '{}' \; > /dev/null

Это попытается прочитать каждый файл на томе, и вы увидите все ошибки чтения на консоли, с именем файла в сообщении об ошибке. Это потенциально очень медленно, поэтому вы можете распараллелить его, если у вас большой объем.

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

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .