Не уверен, что понял вопрос, но:
Запись на стандартный вывод выполняет:
write(1, memory_address, length)
Который записывает байты длины, хранящиеся по адресу памяти _, в файловый дескриптор 1 (1 для stdout, 2 для stderr ). Например, в echo test
,echo
(или оболочка, если echo
встроена в ), выполняет write(1, "test\n", 5)
.
Хотя это немного глупо, вы можете вызвать системный вызов write()
с длиной 0.
С:
write(1, address, 0)
По крайней мере, в Linux системный вызов по-прежнему проверяет, был ли файловый дескриптор открыт в режиме записи или чтения+записи, и что адрес является допустимым адресом (, хотя он не обязательно должен быть доступен для чтения ). ]. Если stdout является сломанным каналом, я не вижу, чтобы он вызывал доставку сигнала SIGPIPE.
Таким образом, выполнение операции нулевого размера строго не эквивалентно отказу от записи вообще, поскольку это может привести к ошибкам.
На практике я обнаружил, что большинство команд избегают write()
, если могут.
Я обнаружил, что echo -n
и printf ''
не выполняют никаких write()
системных вызовов во всех реализациях, которые я пробовал. функции stdio(fputs()
/ printf()
/ fwrite()
... не выполняют никаких write()
, когда вы просите их записать пустую строку ).
Чтобы выполнить запись длиной 0 -, вы можете попробовать:
perl -e 'syswrite(STDOUT, "")'
Или
python -c 'import os; os.write(1, "")'
Которые являются необработанными интерфейсами в этих интерпретаторах для write()
.
Пример:
$ strace -e write /bin/echo -n
$ strace -e write python -c 'import os; os.write(1, "")'
write(1, "", 0) = 0
$ python -c 'import os; os.write(1, "")' >&-
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ python -c 'import os; os.write(1, "")' 1< /dev/null
Traceback (most recent call last):
File "<string>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
$ printf '%s\n' '#include <unistd.h>' 'main(){write(1,(char*)-1,0);}' | strace -e write tcc -run -
write(1, "", 0) = -1 EFAULT (Bad address)
$ printf '%s\n' '#include <unistd.h>' 'main(){write(1,(char*)0,1);}' | strace -e write tcc -run -
write(1, NULL, 1) = -1 EFAULT (Bad address)
$ printf '%s\n' '#include <unistd.h>' 'main(){write(1,(char*)0,0);}' | strace -e write tcc -run -
write(1, NULL, 0) = 0
Вы можете попробовать BackupPC .
Это позволяет создавать инкрементные резервные копии, вы можете решить, как часто их делать, сколько хранить, и когда вы просматриваете их, вы можете увидеть их консолидированные или только фактические инкрементные резервные копии. Он также выполняет дедупликацию полных файлов, если они присутствуют в разных резервных копиях одного и того же или разных хостов.
Скорее всего, он уже упакован для вашего дистрибутива.
Обновление:
Пожалуйста, ознакомьтесь с некоторыми предостережениями здесь:Можно ли использовать tar для полного резервного копирования системы?
Согласно этому ответу, восстановление инкрементных резервных копий с помощью tar чревато ошибками, и его следует избегать. Не используйте описанный ниже метод, если вы не уверены, что сможете восстановить данные, когда они вам понадобятся.
Согласно документации, вы можете использовать инкрементную опцию -g/ --из списка -для создания инкрементных tar-файлов, например.
tar -cg data.inc -f DATE-data.tar /path/to/data
Тогда в следующий раз сделайте что-нибудь вроде
tar -cg data.inc -f NEWDATE-data.tar /path/to/data
Где data.inc — ваши добавочные метаданные, а ДАТА -data.tar — ваши добавочные архивы.
Одним из возможных вариантов является AMANDA, усовершенствованный автоматический сетевой дисковый архиватор штата Мэриленд , который помимо множества других функций также поддерживает добавочное резервное копирование.
Я рекомендую star
для инкрементного резервного копирования, так как было проверено, что star
надежно поддерживает инкрементные дампы и восстановления. Последнее - это то, что не работает с GNU tar, когда вы переименовываете каталоги, хотя это рекламируется уже 28 лет.
Пожалуйста, прочитайте справочную страницу star
по адресу http://schilytools.sourceforge.net/man/man1/star.1.html
Раздел об инкрементном резервном копировании в настоящее время начинается со страницы 53.
Чтобы загрузить исходный код, получите архив schilytools сhttp://sourceforge.net/projects/schilytools/files/
Проверьте Можно ли использовать tar для полного резервного копирования системы? для проверки ошибки GNU tar.
А почему ты сам git
не рассматриваешь?
Описанная вами стратегия после одного полного и двух добавочных резервных копий имеет свои сложности при продолжении. Легко ошибиться, и это может стать очень неэффективным, в зависимости от изменений. Должна быть некая ротация, т.е. время от времени делаешь новый полный бэкап -и потом хочешь оставить старый или нет?
Учитывая рабочий каталог "testdir", содержащий некоторые файлы проекта(и подкаталоги ), git
по умолчанию создает скрытый .git
подкаталог для данных. Это относится к локальным дополнительным функциям контроля версий . Для резервного копирования вы можете заархивировать/скопировать его на носитель или клонировать по сети.
Контроль версий , который вы получаете (без запроса ), является побочным эффектом дифференциального хранилища git.
Вы можете исключить все разветвления/разветвления и т.д. Это означает, что у вас есть одна ветвь под названием «мастер».
Прежде чем вы сможете совершить (фактическую запись в архив/репозиторий git ), вы должны настроить минимального пользователя для файла конфигурации. Тогда вы должны сначала изучить и протестировать в подкаталоге (, возможно, tmpfs ). Иногда Git так же сложен, как и tar.
В любом случае, как говорится в комментарии, :резервное копирование — это просто, а вот восстановление — сложная часть.
К недостаткам git можно отнести только небольшие накладные расходы/избыточность.
Преимущества: :git отслеживает содержимое и имена файлов. Он сохраняет только то, что необходимо, на основе diff (для текстовых файлов не менее ).
У меня есть 3 файла в каталоге. После git init
, git add.
и git commit
у меня 260К .git
дир.
Тогда яcp -r.git /tmp/abpic.git
(хорошее место для сохранения резервной копии :). Я rm
154K jpg, а также изменить один текстовый файл. Я тоже rm -r.git
.
]# ls
atext btext
]# git --git-dir=/tmp/abpic.git/ ls-files
atext
btext
pic154k.jpg
Перед восстановлением файлов я могу получить точные различия:
]# git --git-dir=/tmp/abpic.git/ status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: atext
deleted: pic154k.jpg
no changes added to commit (use "git add" and/or "git commit -a")
Здесь я хочу последовать подсказке git restore
.
Послеgit --git-dir=/tmp/abpic.git/ restore \*
:
]# ls -st
total 164
4 atext 156 pic154k.jpg 4 btext
JPEG вернулся, а текстовый файл btext
имеет не обновленный (сохраняет отметку времени ). Изменения в atext
перезаписываются.
Чтобы воссоединить репозиторий и (рабочий )каталог, вы можете просто скопировать его обратно.
]# cp -r /tmp/abpic.git/.git
]# git status
On branch master
nothing to commit, working tree clean
Файлы в текущем каталоге идентичны архиву .git
(послеrestore
). Новые изменения будут отображаться и могут быть добавлены и зафиксированы без какого-либо планирования. Вам нужно только сохранить его на другом носителе в целях резервного копирования.
После изменения файла вы можете использовать status
или diff
:
]# echo more >>btext
]# git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: btext
no changes added to commit (use "git add" and/or "git commit -a")
]# git diff
diff --git a/btext b/btext
index 96b5d76..a4a6c5b 100644
--- a/btext
+++ b/btext
@@ -1,2 +1,3 @@
This is file b
second line
+more
#]
И точно так же, как git
знает о «+more» в файле «btext», он также будет сохранять эту строку только постепенно.
Послеgit add.
(илиgit add btext
)команда status
переключается с красного на зеленый, а commit
дает вам информацию.
]# git add.
]# git status
On branch master
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: btext
]# git commit -m 'btext: more'
[master fad0453] btext: more
1 file changed, 1 insertion(+)
И вы действительно можете как-то добраться до содержимого:
]# git ls-tree @
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf atext
100644 blob a4a6c5bd3359d84705e5fd01884caa8abd1736d0 btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d pic154k.jpg
И затем первые 4 шестнадцатеричных цифры хэша
]# git cat-file blob a4a6
This is file b
second line
more
Путешествие назад во времени на один коммит:
]# git ls-tree @^
100644 blob 321e55a5dc61e25fe34e7c79f388101bd1ae4bbf atext
100644 blob 96b5d76c5ee3ccb7e02be421e21c4fb8b96ca2f0 btext
100644 blob 2d550ffe96aa4347e465109831ac52b7897b9f0d pic154k.jpg
]# git cat-file blob 96b5
This is file b
second line
Блоб btext имеет другой хэш перед последней фиксацией, остальные имеют такой же.
Обзор будет:
]# git log
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4 (HEAD -> master)
Author: Your Name <you@example.com>
Date: Sun Feb 16 10:51:51 2020 +0000
btext: more
commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <you@example.com>
Date: Sun Feb 16 08:45:16 2020 +0000
added 3 files with 'add.'
Вместо tar-файлов с отметкой времени вручную у вас есть коммиты с сообщением и датой (и автором ). К этим коммитам логически присоединены списки файлов и их содержимое.
Простой git
на 20% сложнее, чем tar
, но вы получаете на 50% больше функциональности.
Я хотел сделать третье изменение OP :изменить файл плюс два новых файла «изображения». Да, но теперь у меня есть:
]# git log
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <you@example.com>
Date: Sun Feb 16 17:56:18 2020 +0000
didn't add the pics before :(
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <you@example.com>
Date: Sun Feb 16 17:54:03 2020 +0000
Two new picture files
Had to change btext...
commit fad04538f7f8ddae1f630b648d1fe85c1fafa1b4
Author: Your Name <you@example.com>
Date: Sun Feb 16 10:51:51 2020 +0000
btext: more
commit 0bfc1837e20988f1b80f8b7070c5cdd2de346dc7
Author: Your Name <you@example.com>
Date: Sun Feb 16 08:45:16 2020 +0000
added 3 files with 'add.'
]#
Так что же конкретно сделал этот парень с вашим именем в своих двух коммитах незадолго до 18:00?
Детали последней фиксации::
]# git show
commit deca7be7de8571a222d9fb9c0d1287e1d4d3160c (HEAD -> master)
Author: Your Name <you@example.com>
Date: Sun Feb 16 17:56:18 2020 +0000
didn't add the pics before :(
diff --git a/picture2 b/picture2
new file mode 100644
index 0000000..d00491f
--- /dev/null
+++ b/picture2
@@ -0,0 +1 @@
+1
diff --git a/picture3 b/picture3
new file mode 100644
index 0000000..0cfbf08
--- /dev/null
+++ b/picture3
@@ -0,0 +1 @@
+2
]#
И проверить второй от -до -последний коммит, чье сообщение анонсирует два изображения:
]# git show @^
commit b0355a07476c8d8103ce937ddc372575f0fb8ebf
Author: Your Name <you@example.com>
Date: Sun Feb 16 17:54:03 2020 +0000
Two new picture files
Had to change btext...
diff --git a/btext b/btext
index a4a6c5b..de7291e 100644
--- a/btext
+++ b/btext
@@ -1,3 +1 @@
-This is file b
-second line
-more
+Completely changed file b
]#
Это произошло из-за того, что я попытался git commit -a
создать ярлык git add.
, а эти два файла были новыми(неотслеживаемыми ). Он отображался красным с git status
, но, как я уже сказал, git не менее хитрый, чем tar или unix.
«Ваша дебютантка просто знает, что вам нужно, а я знаю, чего вы хотите» (или наоборот. Дело в том, что это не всегда одно и то же)
I tried rsync, but it doesn't seem to be able to do what I want, or more likely, I don't know how to make it do that.
I know I could probably create a script that runs a diff and then selects the files to backup based on the result (or more efficiently, just get a checksum and compare), but I want to know if there's any utility that can do this a tad easier :)
rsync
— это именно та программа, которая копирует на основе diff. По умолчанию он копирует только тогда, когда есть разница во времени или размере последнего -изменения, но он может даже сравнивать по контрольной сумме с -c
.
Проблема в том, что вы tar
копируете резервные копии. Это становится легче, если вы этого не сделаете. Я даже не знаю, зачем ты это делаешь. Это может иметь смысл, если вы сжимаете их, но вы даже этого не делаете.
В статье Википедии об добавочном резервном копировании есть пример rsync
команды, которая работает приблизительно:
rsync -va \
--link-dest="$dst/2020-02-16--05-10-45--testdir/" \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/"
Он выполняет жесткую привязку файлов из предыдущей резервной копии, если они не изменились по сравнению с источником. Там также --copy-dest
, если вы хотите, чтобы он копировал вместо этого (, это все еще быстрее, когда $dst
является удаленным или на более быстром диске ).
Если вы используете файловую систему с подтомами, например btrfs, вы также можете просто сделать снимок из предыдущей резервной копии перед rsync. Снимки создаются мгновенно и не занимают дополнительного места[1].
btrfs subvolume snapshot \
"$dst/2020-02-16--05-10-45--testdir" \
"$dst/2020-02-17--03-24-16--testdir"
Или, если вы используете файловую систему, которая поддерживает рефлинки, вы также можете сделать это. Рефлинки создаются путем создания нового индексного дескриптора, но ссылающегося на те же блоки, что и исходный файл, реализуя поддержку COW. Это по-прежнему быстрее обычного копирования, поскольку не считывает и не записывает данные, а также не занимает дополнительного места[1].
cp --reflink -av \
"$dst/2020-02-16--05-10-45--testdir" \
"$dst/2020-02-17--03-24-16--testdir"
В любом случае, однажды сделав что-то подобное, вы можете просто сделать обычное rsync
копирование различий:
rsync -va \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/"
Однако вы можете добавить --delete
, что заставит rsync удалять файлы из места назначения, которых больше нет в источнике.
Другой полезный параметр — -i
или --itemize-changes
. Он производит краткий машиночитаемый вывод, описывающий изменения, которые делает rsync. Обычно я добавляю эту опцию и набираю вид:
rsync -Pai --delete \
"$src/testdir/" \
"$dst/2020-02-17--03-24-16--testdir/" \
|& tee -a "$dst/2020-02-17--03-24-16--testdir.log"
для записи изменений с помощью легко grep
доступных файлов. |&
предназначен для передачи как stdout, так и stderr.
-P
является сокращением от --partial
и --progress
. --partial
сохраняет частично переданные файлы, но, что более важно, --progress
сообщает о ходе выполнения -файла.
Вышеупомянутые решения приводят к каталогам, которые, кажется, содержат все. Даже если это так, в целом для любого количества / частоты резервных копий они будут занимать примерно столько же места, сколько и обычные tar-архивы только с изменениями. Это связано с тем, как работают жесткие ссылки, рефлинки и моментальные снимки. Использование полосы пропускания при создании резервных копий также будет таким же.
Преимущества::
foo
, пометить его foo.DELETED
или сделать что-то сложное. Например, я никогда не использовал дублирование, но, глядя на его документацию, кажется, что он кодирует удаления, добавляя пустой файл с тем же именем в новый tar и сохраняя исходную подпись файла в отдельном файле.sigtar. Я предполагаю, что он сравнивает исходную подпись с подписью пустого файла, чтобы различать удаление файла и изменение фактического пустого файла. Если кто-то по-прежнему хочет настроить каждую резервную копию только для хранения файлов, которые (добавлены или изменены ), тогда можно использовать решение --link-dest
, описанное выше, а затем удалить жесткие ссылки, используя что-то вроде следующего:
find $new_backup -type f ! -links 1 -delete
[1] Строго говоря, они используют дополнительное пространство в виде повторяющихся метаданных, таких как имя файла и тому подобное. Однако я думаю, что любой счел бы это незначительным.
Это не совсем то, что вы запрашиваете, потому что он не использует tar. Но он использует rsync, и мне это очень помогло. Одна из способностей, которая мне действительно нравится, — это возможность сбрасывать добавочные точки восстановления с течением времени, не теряя точек до или после той, которую я сбрасываю. Это позволяет мне, например, иметь ежедневные резервные копии за последние 2 недели, а затем уменьшать их, как только им исполняется 2 недели, чтобы они были еженедельными в течение пары месяцев, а затем еще больше уменьшать их, пока они не будут ежемесячными в течение квартала или двух., а затем проредите их примерно ежеквартально в течение нескольких лет. У меня есть скрипт на Python, которым я могу поделиться, который может автоматически обрезать их, если хотите. (Очевидно, что на это не распространяется НИКАКИХ ГАРАНТИЙ, поскольку автоматическое удаление резервных копий компьютером звучит немного пугающе.)
Я использую пул и файловую систему ZFS для хранения резервных копий. С файловой системой ZFS, которая, к счастью, (! )теперь можно использовать в Linux, вы можете делать снимки. Когда вы записываете в файловую систему, для которой был создан моментальный снимок, она (ловко )записывает новую версию только измененных блоков, таким образом делая ее инкрементной резервной копией. Еще проще то, что все ваши снимки могут быть смонтированы как полная (файловая система Unix только для чтения ), которую вы можете использовать для просмотра и копирования с помощью всех ваших обычных инструментов. Хотите увидеть, как этот файл выглядел 2 месяца назад?Просто перейдите в нужную папку и используйте less или vim или что-то еще, чтобы посмотреть на нее. Хотите увидеть, когда (взломанная )установка WordPress, резервную копию которой вы создавали, сошла с рельсов? Просто выполните grep для опознавательного знака с чем-то вродеgrep -in /zfsbackup/computername/.zfs/snapshots/*/var/www/html/wp-config.php" "somebadstring"
Вы даже можете использовать систему Linux LUKS для шифрования диска, а затем представить сопоставленное устройство как «диски» для ZFS, что даст вам зашифрованную резервную копию.
Если вам когда-нибудь понадобится перенести резервные копии на новый диск, вы можете использовать функцию отправки и получения zfs для перемещения всей файловой системы.
Прошел год или два с тех пор, как я его настроил (Я просто добавляю добавочные резервные копии и какое-то время не нуждался в обновлении моего резервного диска ), так что это будут приблизительные инструкции. Потерпите меня, а еще лучше отредактируйте их.
Во-первых, убедитесь, что у вас установлены zfs, rsync и, если вы хотите шифровать резервные копии, инструменты LUKS.
Во-первых, создайте любой макет раздела на резервном диске. (Возможно, вы захотите создать небольшой незашифрованный раздел со сценариями для запуска резервного копирования.)
Затем, если вы хотите зашифровать диск, зашифруйте раздел с помощью LUKS. (В примере предполагается резервный диск /dev/sde и раздел /dev/sde2, поскольку /dev/sde1, вероятно, является скриптом):
sudo cryptsetup luksFormat /dev/sde2
(Введите надежную парольную фразу ).
Если вы занимаетесь шифрованием диска, теперь вам нужно открыть том:
sudo cryptsetup luksOpen /dev/sde2 zfsbackuppart1
(Теперь должна быть доступна незашифрованная версия необработанного устройства (, сопоставленная )в /dev/mapper/zfsbackuppart1 ).
Теперь создайте пул ZFS (группу дисков (с ), содержащих данные, несколько дисков/устройств можно использовать для RAID, если хотите):
sudo zpool create zfsbackup /dev/mapper/zfsbackuppart1
Будет создан пул ZFS с именем «zfsbackup».
Теперь,создайте файловую систему для каждой машины, для которой выполняется резервное копирование:
sudo zfs create zfsbackup/machinename
И создайте папку для каждого раздела, для которого вы хотите создать резервную копию с исходной машины:
sudo mkdir /zfsbackup/machinename/slash/
sudo mkdir /zfsbackup/machinename/boot/
Затем используйте rsync для копирования файлов туда:
sudo rsync -avx --numeric-ids --exclude.gvfs / /zfsbackup/machinename/slash/ --delete-after
sudo rsync -avx --numeric-ids --exclude.gvfs /boot/ /zfsbackup/machinename/boot/ --delete-after
Сделать снимок:
zfs snapshot zfsbackup/machinename@`date +%F_%T`
Чтобы отключить диск, когда закончите:
zpool export zfsbackup
# Next line, for each underlying encrypted block device, if using encryption:
cryptsetup luksClose zfsbackuppart1
И настроить его при создании еще одной резервной копии в будущем, перед приведенными выше командами rsync:
cryptsetup luksOpen /dev/sde2 zfsbackuppart1
zpool import zfsbackup
Дайте мне знать, если вам нужна дополнительная информация об этом подходе или вас интересует сценарий для прореживания резервных копий по мере их удаления в прошлое.
И да, таким образом вы можете сделать резервную копию всей системы --вам просто нужно создать разделы/файловые системы (, которые не обязательно должны соответствовать исходной структуре --отличный способ переноса данных! ), настройте /etc/fstab и установите GRUB, чтобы он пересканировал/пересобрал конфигурацию GRUB.
Найдите «удобную утилиту моментального снимка файловой системы Майка». По сути, это просто удобный сценарий, который оборачиваетrsync
для создания инкрементных резервных копий каталога с чередованием. Это сведет к минимуму использование памяти за счет обратной связи с более ранними инкрементными резервными копиями для всех файлов, которые не изменились.
См. Easy Automated Snapshot -Резервное копирование в стиле Linux и Rsync для полного введения вместе с объяснением того, как это работает.
Я бы порекомендовал вам взглянуть на Резервную копию Борга .
Это будет обрабатывать резервные копии,:
Дедуплицированы. Это косвенно делает его дифференциальным резервным копированием, но имеет больше преимуществ :
.Сжаты
Он будет управлять удалением старых резервных копий, используя такие правила, как «хранить одну ежедневную резервную копию в течение недели, одну еженедельную резервную копию в течение месяца, одну ежемесячную резервную копию в течение года»
Его очень легко настроить и использовать.
Рассмотрите возможность использования bup:
Предостережения, которые я нашел до сих пор:
bup
использует блокировку файла -в папке архива. Это означает, что файловая система, в которой размещается архив, должна поддерживать блокировку файла -. Это может быть проблема с общими ресурсами SMB. (Однако NFS работает.)ssh
)требует установки bup
. /
). Для git
это не проблема.но bup ls
смущается ими, так что не делайте этого. (Вы можете изменить название ветки с помощью подходящей команды git branch -m
, если вас это укусит.)В дополнение ко всем отличным решениям, представленным выше, у меня есть еще один подход. Поскольку вы не упомянули используемую файловую систему, я предполагаю, что вы не используете zfs или btrfs. Эти файловые системы имеют встроенные -возможности для создания моментальных снимков, которые не являются копиями всей файловой системы, а только инкрементами. Типичным подходом был бы такой:
Например, если вы установили срок хранения 5 дней, вы можете вернуться на 5 дней назад.
Очень старая команда BSD rdump создавала уровни резервного копирования. Уровень 0 поддерживает всю файловую систему. Уровень 1 будет создавать резервные копии того, что изменилось с нулевого уровня, Уровень 2 будет делать все резервные копии, начиная с уровня 1. Чтобы действительно файлы требовали применения нуля к файловой системе, затем уровня 2, за которым следует 3 (, если используется ). Rdump имеет несчастье записывать на ленту...
Следующий сценарий оболочки сделает то, что вы хотите, используя tar, find и egrep. Он использовал -более новый флаг поиска, сравнивая «более новый» с «затронутым», который был создан при последнем запуске скрипта. В последний раз сценарий запускался на Solaris 4.3bsd в 1990-х годах для копирования исходных файлов между машиной разработки UNIX и ноутбуками с помощью kermit.
Сценарий довольно ненадежен, потому что, если сценарий «касается» файла времени обновления, а tar дает сбой, то файл времени необходимо создавать заново. Файл tar имеет имя дата+час+минута+секунда. `#!/bin/sh -vx
echo finding newer files than update...
cd /home/programs/gis
HOME_LOC=/home/programs/gis/
TAR_FILE=${HOME_LOC}stage/u`date +%m%d%H%M`.tar.bz2
#run find one using the -o (or) syntax
(
find. -newer ${HOME_LOC}/update \
\( -name '*.[hcsf]' -o -name '*.asm' \
-o -name '*.ma*' -o -name '*.cpp' \
-o -name '*.msg' -o -name '*.hpp' \
-o -name 'Makefile' -o -name '*.inl' \
-o -name 'grid*.*' -o -name '*.glb' \) \
-print ) | \
egrep -v 'SCCS|stage|local.h' | tee /usr/tmp/x.$$
echo copying files:
tar -cjhf ${TAR_FILE} `cat /usr/tmp/x.$$`
# rm /usr/tmp/x.$$
if test -r ${TAR_FILE}
then
touch ${HOME_LOC}/update
fi
`