У меня есть несколько систем, работающих под управлением btrfs, и я хотел бы использовать подобъем btrfs send / receive в качестве решения для резервного копирования. Я хочу посылать ежедневные инкременты в удаленно настолько эффективно, насколько это возможно. Это означает, что я хочу избежать отправки изменений в ежедневном инкременте, а затем отправлять те же изменения в ежемесячном приросте.
В частности, я хочу генерировать ночные инкременты как таковые:
btrfs subvolume snapshot /home /backup/volume-date-daily
btrfs send -p /backup/volume-previous-daily -f daily-date /backup/volume-date-daily
push daily-date to remote
Через некоторое время я хотел бы объединить ежедневные инкременты в ежемесячные инкременты без повторной отправки всех этих данных от клиента. Если я распаковываю все инкременты (btrfs receive
), то удаляю все промежуточные подобъемы, которые мне не нужны, достаточно ли мне оставшегося подобъема для распаковки всех будущих ежедневных инкрементов, сгенерированных клиентом?
Например, , на сервере есть ежедневники 1-30 от клиента. Я распаковываю их и стираю все подобъемы, кроме ежедневных 30. Когда я получаю ежедневно от клиента 31, могу ли я распаковать это, используя btrfs receive
?
С инструментов BTRFS 3.12 и ядро Linux 3.13, ответ нет. При сериализации данные BTRFS (возрастающий или иначе) десериализовываются (btrfs receive
), и промежуточный удаленный объем, последние объемы обновляются. Когда они повторно сериализируются (btrfs send
), у них есть различные идентификаторы. Последние сериализированные объемы, которые вернулись к их родительскому объему идентификатором, не могут найти своего родителя, из-за измененного идентификатора.
не известно, существует ли какое-либо обходное решение для этого поведения.
Вот то, что возможно:
btrfs receive
), удаляют некоторые промежуточные объемы и повторно сериализируют все объемы после удаленных объемов.