Поскольку вы используете 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 года, и никогда не было проблем с восстановлением инкрементных резервных копий с использованием эти программы.