Есть два возможных ответа в зависимости от того, что вы подразумеваете под «поврежден из-за сбоя диска».
Если вы имеете в виду простое повреждение данных в покое
BTRFS обрабатывает это сам, прозрачно для пользователя. Он проверяет все, включая данные в снимках, внутри, а затем проверяет контрольные суммы при чтении каждого блока. Есть несколько исключений из этого:
- Если том смонтирован с
nodatasum или nodatacow , у вас не будет контрольной суммы блоков данных. В большинстве случаев вам не следует монтировать эти опции, поэтому это не должно вызывать проблем.
- Любые файлы, для которых установлен атрибут
NOCOW (C в выводе команды lsattr ), также не проверяются. У вас вряд ли будут какие-то действительно важные файлы с этим набором атрибутов (в файлах журнала systemd он установлен, но это все, если вы не установите его вручную).
Если вы имеете в виду нетривиальное уничтожение данных на томе из-за потери слишком большого количества устройств
Вы не можете защититься от этого, если у вас есть еще одна копия данных. В значительной степени, если вы потеряли больше устройств, чем столько профилей хранения для тома могут выдержать, ваши данные исчезнут, и ничто не вернет их вам, за исключением восстановления из резервной копии.
Относительно вашего конкретного случая
Проблемы, о которых вы говорите при отправке / получении, вероятно, являются побочным эффектом тех неисправимых ошибок, о которых сообщает scrub. Когда BTRFS не может прозрачно исправить ошибку (обычно потому, что блок хранится с использованием профиля, который не может выполнить восстановление, например single или raid0), он возвращает ошибку ввода-вывода, что приведет к сбою операции отправки. Таким образом, у вас не будет уже поврежденных резервных копий, если вы используете отправку / получение (и на самом деле вы не будете использовать большинство других инструментов, любое хорошее программное обеспечение для резервного копирования выдаст ошибку, если не сможет прочитать файл ).
В этом случае кажется, что неисправимые ошибки полностью относятся только к данным и не являются моментальными снимками. Вы можете довольно легко (хотя и не очень быстро) выяснить, какие файлы имеют проблемы, смонтировав исходный том где-то отдельно и выполнив следующую команду из того места, где он смонтирован:
find . -exec cat '{}' \; > /dev/null
Это попытается прочитать каждый файл на томе, и вы увидите все ошибки чтения на консоли, с именем файла в сообщении об ошибке. Это потенциально очень медленно, поэтому вы можете распараллелить его, если у вас большой объем.
После того, как вы нашли и разберетесь с этими файлами, у вас больше не будет проблем. Если вы увидите, что эти проблемы повторятся в ближайшем будущем после их устранения, вам следует проверить аппаратное обеспечение, поскольку что-то незаметно повреждает данные.
