У Вас есть две перепутанные файловых иерархии: /var/chef
и /var/chef/chef
. Похоже, что Вы редактируете один и затем читаете назад другой.
scp -r root@198.xxx.xxx.xxx:/var/chef .
создает a chef
каталог в текущем каталоге. Если Вы выполнили это от /var/chef
.
Предложенные команды ужасны. Забудьте все, что Вы читаете в том учебном руководстве.
scp -r
не сохраняет полномочия файла или времена. Использовать scp -rp
сохранить их.
rsync -r
не сохраняет полномочия файла или времена. Забудьте что -r
опция существует. Использовать rsync -a
вместо этого, который сохраняет все обычные метаданные. Всегда передавайте -a
опция к rsync, если у Вас нет серьезного основания не к.
Когда Вы пишете rsync -a /path/to/source /path/to/destination
, это создает названный подкаталог source
под destination
. Если Вы хотите синхронизироваться /path/to/source
с /path/to/destination
вместо этого, добавьте финал /
в конце места назначения: rsync -a /path/to/source /path/to/destination/
копии /path/to/source/somefile
кому: /path/to/destination/somefile
.
Очень важно сохранить время изменения файла. Тем путем Вы знаете, когда файл был в последний раз изменен. Ваши инструменты также знают, когда файл был изменен. В частности, синхронизация большого каталога, в котором не было изменено большинство файлов, намного быстрее, если времена файла надежны. Rsync пропустит файл быстро, если имя, размер и время изменения будут тем же с обеих сторон.
Можно сказать rsync передавать только файлы, которые являются более новыми на исходной стороне путем добавления -u
опция (rsync -au SOURCE DESTINATION
). Это ограничивает риски, если файлы были также отредактированы на целевой стороне: Вы не сотрете более новую версию, которая находится на целевой стороне с более старой копией на исходной стороне. Однако Вы не можете надежно обнаружить конфликты: если файл был отредактирован с обеих сторон, какой бы ни версия имеет новое время изменения, победит.
Rsync является инструментом для синхронизации данных в одном направлении. Не используйте его для синхронизации в обоих направлениях. Вместо этого используйте Унисон. Унисон ведет список версий файла каждый раз, когда Вы выполняете его и будете жаловаться громко, если существует когда-нибудь конфликт (тот же файл, отредактированный независимо с обеих сторон). Пока нет никакого конфликта (т.е., пока каждый файл только изменяется на одной стороне между синхронизациями), Унисон объединит изменения на этих двух сторонах.
Для установки Унисона используйте GUI или создайте предпочтительный названный файл ~/.unison/chef.prf
содержа
root = /var/chef
root = server.example.com:/var/chef
times = true
Выполненный unison -auto chef
синхронизировать эти два дерева.
Вместо того, чтобы синхронизировать файлы, необходимо подвергнуть файлы управлению версиями. При внесении изменений передайте их репозиторию. Для развертывания изменений проверьте их на сервере.
Отличный ответ :Большое спасибо.
Я использовал его для вставки трех столбцов, каждый из которых находится в сжатом файле.
Только для обмена :source 3200 машин redhat, примерно 250 миллионов точек в день...
Это не совсем тот способ, которым мы получаем все файлы локально, но уловил идею (мы используем ansible
в реальной задаче)
for i in $(cat list_of_hostnames.txt)
do
sadf -U -- -A <file from yesterday> | pigz -9 > host_date_file.tsv.gz
done
Предположим, мы получаем все такие файлы в рабочем каталоге:
pigz -cd *.tsv.gz| sed -E 's/\t/\n/g' | split --numeric-suffixes=1 -nr/6 - kk.
После такой команды вы получите шесть сжатых файлов с именами от kk.01
до kk.06
, соответствующих имени хоста, интервалу, метке времени в секундах от эпохи, устройству, метрике и значению.
Просто для экономии места:
rm kk.02
(Мне не нужен интервал с метками времени ), а затем
pigz -9 kk.0[13456]
и сейчас я использую:
paste <(zcat kk.05.gz ) <(zcat kk.01.gz) <(zcat kk.04.gz) <(zcat kk.06.gz) | grep '%idle' | pigz -9 > metric_host_device_value.tsv.gz