В настоящее время я использую tar для записи своих резервных копий (файлов ntbackup) на ленточный накопитель, загружаемый автозагрузчиком.
Пример: tar -F /root/advancetape -cvf /dev/st0 *.bkf (/ root / advancetape просто имеет логику перехода к следующей ленте, если она доступна, или уведомления о замене лент)
Недавно мне вручили требование шифровать наши резервные копии на магнитной ленте. Я могу легко зашифровать данные с помощью GPG. Проблема, с которой я столкнулся, заключается в том, как мне записать это на несколько лент с той же логикой, которую tar использует для продвижения лент после заполнения текущей? Я не могу сначала записать зашифрованный файл на диск (2 + ТБ). Насколько я могу судить, tar не принимает двоичный ввод от stdin (он ищет имена файлов). Любые идеи? :(
Я использую этот скрипт:
#!/bin/sh
TAPE="/dev/nst0"
mt-st -f $TAPE setblk 0
mt-st -f $TAPE status
totalsize=$(du -csb . | tail -1 | cut -f1)
tar cf - . | \
gpg --encrypt --recipient target@key.here --compress-algo none | \
pipemeter -s $totalsize -a -b 256K -l | \
mbuffer -m 3G -P 95% -s 256k -f -o $TAPE \
-A "echo next tape; mt-st -f $TAPE eject ; read a < /dev/tty"
Вот основные моменты, чтобы адаптировать его под свои нужды:
tar читает из текущего каталога и выводит в stdout. Таким образом, tar не занимается сменой лент или шифрованием.gpg отключено сжатие, так как это значительно замедляет процесс (100 МБ / с + до 5 МБ / с)pipemeter используется для отслеживания процесса и определения приблизительного времени, пока все данные не будут записаны на ленту - его можно удалить, если он не нуженmbuffer буферизует данные в память - в этом примере используется буфер объемом 3 ГБ, настраивайте его по мере необходимости - чтобы ленточный накопитель работал дольше, прежде чем закончились данные, уменьшая "блеск обуви" ленты.-A вариант mbuffer обрабатывает несколько лент, выталкивая ленту по достижении конца и ожидая Enter клавишу, которую нужно нажать после загрузки следующей ленты. Это где твой /root/advancetape скрипт может пойти.Одна проблема, о которой следует помнить при использовании этого с лентами LTO:
mbuffer записывает блоками по 256k. У меня это хорошо работает с приводом LTO3, однако tar любит использовать другой размер блока. Это в сочетании с тем, что mbuffer обрабатывает охват лент, а не tar, означает, что вам нужно будет снова прочитать данные с ленты через mbuffer а затем пройти через gpg и дальше tar. Если вы попытаетесь извлечь его прямо с ленты с помощью tar (даже если вы пропустили шифрование), оно, скорее всего, не сработает и обязательно сломается, как только достигнет конца первой ленты, не давая вам возможности перейти на следующую ленту.Предлагаю вам взглянуть на этот вариант:
-I, --use-compress-program PROG
filter through PROG (must accept -d)
Возможно, вам потребуется написать сценарий, который принимает входные данные со стандартного ввода и шифрует их в стандартный вывод, но он должен работать. -D предназначен для распаковки, и в этом случае вам нужно будет расшифровать ввод.
Вы можете реализовать это в своем сценарии -F. Вместо того, чтобы tar записывал непосредственно в / dev / st0, используйте временную промежуточную область. Убедитесь, что вы явно указали размер тома с помощью -L. Tar запишет в файл до байтов данных, а затем вызовет ваш сценарий -F. Затем ваш сценарий может запустить gpg для файла и отправить его на ленту (а затем удалить часть архива из области подготовки).
Для этого требуется только, чтобы в вашей файловой системе было доступно (x2) пространство на одной ленте.
Видеть http://www.gnu.org/software/tar/manual/html_node/Multi_002dVolume-Archives.html#SEC162 для получения дополнительной информации о переменных, доступных для вашего сценария -F.
РЕДАКТИРОВАТЬ: Также обратите внимание, что это полностью непроверенная идея! Я думал сделать что-то подобное, чтобы обеспечить сжатие многотомных архивов, но на самом деле я этого не реализовал.