Мне нужно скопировать снимки виртуальных машин, работающих на серверах Proxmox (KVM), и скопировать снимки во внешнее хранилище.
Большинство снимков имеют размер несколько ГБ, но некоторые довольно большие, до 200 ГБ. Я бы предпочел сжать и скопировать снимки за один раз, например:
xz -c dumpfile | scp offsite
Проблема возникает из-за размера файла дампа и других заданий, которые должны выполняться в то время, когда это может занять 12 часов или более, в течение которого может произойти много прерываний потока данных.
Используя rsync, я мог бы возобновить передачу, если она была прервана, но тогда мне пришлось бы сжать весь файл перед его отправкой, что потребовало бы еще 150g сверх 250g, выделенных для моментального снимка. Поскольку хранилище на сервере является премиальным (только ssd), я бы предпочел не выделять это дополнительное дисковое пространство.
Возможно, решением может стать разделение сжатого вывода на более мелкие части в стиле pkzip и их передача в очередь по мере их готовности? Похоже, что у Tar есть многотомная опция (-m), которую, возможно, можно было бы использовать. Проблема в том, что процесс сжатия необходимо остановить до тех пор, пока не будет перенесена последняя сжатая часть.
Я ищу здесь идеи, а не конкретное решение. Я чувствую, что упустил очевидный вариант. По возможности предпочел бы использовать стандартное программное обеспечение Linux.
Я собирался предложить ChunkFS файловая система fuse, которая позволяет любому пользователю монтировать файл и видеть его разделенным как каталог файлов, каждый из которых является кусок некоторого заданного размера. Затем вы можете синхронизировать эти файлы с удаленным компьютером и объединить их там.
Однако отмечу, что тот же человек, Флориан Зумбиль, также написал ChunkSync, который как бы сочетает в себе функции ChunkFS и rsync (без использования fuse). Он был разработан для обеспечения возможности инкрементного резервного копирования большого файла (например, зашифрованной файловой системы), когда изменяются только небольшие части большого файла. Он эффективно разбивает файл на фрагменты и создает резервную копию каждого фрагмента, используя жесткие ссылки для фрагментов, которые не изменились с момента последнего резервного копирования. Вы можете указать место назначения с помощью ssh. Даже при создании единственной резервной копии это должно быть полезно.
Классический случай RTFM, извините. Внимательно читая TFM, выясняется, что vzdump предлагает параметр --compress, который сжимает дамп на лету, поэтому я еще больше уменьшаю необходимое пространство. Затем я перехожу к rsync и отправляю дамп compressd на сервер резервного копирования и удаляю дамп с гипервизора.
Окончательный сценарий стал
vzdump $VZID --mode snapshot --compress lzo --mailnotification failure --mailto my@email.address \
&& rsync -e ssh vzdump-qemu-${VZID}-* backup:/backup \
&& rm -f vzdump-qemu-${VZID}-* \
|| mail my@email.address -s "transfer of $VZID failed" < vzdump-qemu-${VZID}-*.log
~