Сохраняет ли инкрементное резервное копирование GNU tar снова весь файл, даже если отличается только atime или mtime?
Поскольку вы используете bash, вы можете использовать ассоциативные массивы:
#!/usr/bin/env bash
declare -A ip_list=(["ip_1"]="mykey1.pem" ["ip_2"]="mykey2.pem")
for ip in "${!ip_list[@]}"; do
ssh -i "${ip_list[$ip]}" myuser@"$ip" << 'ENDSSH'
[A LOT OF STUFF]
ENDSSH
done
Обратите внимание, что ассоциативные массивы, в отличие от обычных массивов с индексами, не сохраняются в определенном порядке, поэтому нет гарантии, что ip_1будет обработан раньше ip_2.
Если вам нужно использовать простую, совместимую с POSIX оболочку, создайте файл с файлами ip и ключей, по одному на строку:
$ cat iplist.txt
ip1 mykey1.pem
ip2 mykey2.pem
Затем используйте этот скрипт:
#!/bin/sh
while read -r ip key; do
ssh -i "$key" myuser@"$ip" << 'ENDSSH'
[A LOT OF STUFF]
ENDSSH
done
И запустите его с помощью:
sh /path/to/script < /path/to/iplist.txt
Но если вы пойдете по этому пути, подход Стефана лучше.
Использование gtarдля инкрементных резервных копий ненадежно, но это не результат неправильной обработки меток времени.
Любой инструмент резервного копирования, который работает в пользовательской среде и поэтому не может проверять внутренние структуры файловой системы, как это делается, например,. zfs sendдолжен обрабатывать временные метки таким же образом, иначе он не сможет предоставить правильную инкрементную резервную копию.
atimeне имеет значения для резервных копий, так как это только намек на то, что файл был прочитан, но не на то, был ли файл изменен.mtimeможет показаться интересным с первого взгляда, но также не имеет значения. Это связано с тем, чтоmtimeфайла может быть установлено в любое значение программами пользовательского пространства.ctime— единственная важная отметка времени для инкрементных резервных копий, так как это единственная отметка времени, которой нельзя манипулировать.
Поскольку ctimeнельзя манипулировать, а ctimeобновляется как для содержимого, так и для изменения метаданных, инструмент резервного копирования должен архивировать содержимое файла и метаданные файла всякий раз, когда ctimeобновляется.
В результате файл, который, по-видимому, не изменился mtime, все еще может иметь измененное содержимое и, следовательно, должен быть в резервной копии
Наконец, :GNU tar не реализует метод, о котором вы просили. Поведение жестко закодировано.
Однакоstarпредлагает вариант -dumpmeta, созданный в 2004 году для экспериментов с добавочными резервными копиями. starоднако явно предупреждает об использовании этой опции, см. справочную страницу:
-dumpmeta changes the behavior of star in incremental dump mode. If -dumpmeta is used and only the inode change time (st_ctime) of a file has been updated since the last incremental dump, star will archive only the meta data of the file (e.g. uid, permissions, ...) but not the file content. Using -dumpmeta will result in smaller incremental dumps, but files that have been created between two incrementals and set to an old date in st_mtime (e.g. as a result from a tar extract) will not be archived with full content. Using -dumpmeta thus may result in incomplete incremental dumps, use with extreme care.
Метод, используемый starпо умолчанию, используется ufsdumpи ufsrestoreпримерно с 1981 года, и этот метод используется starс февраля 2005 года, и никогда не было проблем с восстановлением инкрементных резервных копий с использованием эти программы.