Как я могу проверить, правильно ли работает отправка / получение btrfs?
Вы не передаете никаких аргументов в свою mainфункцию. Если вы хотите, чтобы эта функция получала те же аргументы, что и в скрипте, передайте их вместе с:
main "$@"
Вместо:
main
Также относится к вашему сценарию:
- разница между «function foo (){}» и «foo (){}»
- Почему printf лучше, чем echo?
- Последствия для безопасности, если забыли заключить переменную в кавычки в оболочках bash/POSIX
- вы хотите вывести ошибки на stderr:
echo >&2 Unknown option - вы хотели бы вернуть не -нулевой статус выхода при ошибке(
return 1) - при вызове
getoptsв функции рекомендуется изначально устанавливатьOPTINDв 1, еслиgetoptsбыл вызван до (, например, при предыдущем вызове функции ).
У меня есть более десяти систем резервного копирования, основанных именно на последней части того, что вы сказали. Прямые каналы никогда не были для меня вариантом, так как я имею дело с резервным копированием по сети размером> 1 ТБ. Не мог рисковать потерять ни единого бита и тратить часы работы.
Моя окончательная настройка выглядит следующим образом.
Фаза начальной загрузки:
- Сделать первый полный снимок
- Отправить снимок в локальный файл (-f опция)
- Rsync или передача файла моментального снимка на физический носитель на удаленный сайт.
- Удаленное получение первого снимка
Инкрементальная фаза:
Новый локальный снимок
Локальное создание и отправка в файл разницы между текущим и последним снимком
Повторная синхронизация с удаленным сайтом
Удаленный импорт переданного файла моментального снимка
Логика очистки (подумать о хранении, удалить старые снимки...)
Это работает уже 3 года. В худших случаях, когда снимки не совпадают, достаточно удалить последние два (1 локальный, 1 удаленный ), чтобы он снова работал при следующей отправке.
Удачи
TL;DR :Если Received UUIDи флаг readonlyустановлен, маловероятно, что что-то пошло не так, если только речь не идет о невнимательности или злом умысле.
Как @timakro уже сказал в своем ответе, Received UUIDне устанавливается, пока передача не будет завершена. Так же как и флаг readonly. Это, в сочетании с тем фактом, что каждая команда в потоке проверяется контрольной суммой (и тем, что, насколько я понимаю, отправляемые метаданные также включают контрольные суммы ), делает весьма маловероятным, что вы в конечном итоге получите поврежденный снимок на приемной стороне с установленными параметрами readonlyи Received UUID. Если какой-либо из них не установлен, btrfs откажется использовать этот снимок в качестве эталона в будущем btrfs receive.
Повреждение полученного моментального снимка может быть преднамеренным повреждением, если получен специально созданный поток, или если какой-либо процесс или пользователь изменил содержимое полученного моментального снимка во время его получения. Из справочной страницы btrfs-receive:
BUGS
btrfs receive sets the subvolume read-only after it completes successfully. However, while the receive is in progress, users who have write access to files or directories in the receiving path can add, remove, or modify files, in which case the resulting read-only subvolume will not be an exact copy of the sent subvolume.
If the intention is to create an exact copy, the receiving path should be protected from access by users until the receive operation has completed and the subvolume is set to read-only.
Additionally, receive does not currently do a very good job of validating that an incremental send stream actually makes sense, and it is thus possible for a specially crafted send stream to create a subvolume with reflinks to arbitrary files in the same filesystem. Because of this, users are advised to not use btrfs receive on send streams from untrusted sources, and to protect trusted streams when sending them across untrusted networks.
Также стоит отметить, что можно отключить флаг readonlyдля подтома, изменить что-то, а затем снова включить его. Если это было сделано с любой стороны, все гарантии выбрасываются в окно.
Обратите внимание, что передача вывода в файл и передача этого файла не обеспечивает какую-либо защиту от вышеуказанного. Лично я не вижу абсолютно никаких причин, по которым было бы небезопасно передавать вывод btrfs sendнапрямую в ssh. Преимущество промежуточного хранения потока в файлах состоит в том, что это позволяет возобновить прерванную передачу при ненадежном соединении, но не дает никаких гарантий целостности данных.
Хороший (, хотя и не дурацкий -способ доказательства )того, что полученный снимок совпадает с отправленным, заключается в использовании rsync -avcn --del path/to/sent/snapshot/ user@remote:path/to/received/snapshot/.