Утилита резервного копирования Linux для инкрементного бэкапа
Не уверен, что понял вопрос, но:
Запись на стандартный вывод выполняет:
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(хорошее место для сохранения резервной копии :). Я rm154K 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
Вышеупомянутые решения приводят к каталогам, которые, кажется, содержат все. Даже если это так, в целом для любого количества / частоты резервных копий они будут занимать примерно столько же места, сколько и обычные tar-архивы только с изменениями. Это связано с тем, как работают жесткие ссылки, рефлинки и моментальные снимки. Использование полосы пропускания при создании резервных копий также будет таким же.
Преимущества::
- Резервные копии легко восстанавливаются с помощью rsync и быстрее, поскольку rsync передает только различия из резервной копии.
- их проще просматривать и изменять при необходимости.
- Удаление файла может быть закодировано естественным образом как отсутствие файла в новых резервных копиях. При использовании 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:
- Не нужно беспокоиться о различиях между полными, инкрементными и декрементными резервными копиями.
- Резервные копии выполняются так же быстро, как инкрементные резервные копии
- Восстановление так же просто, как из полных резервных копий
- На основе формата хранения git , расширенного для поддержки действительно больших резервных копий
- Полная дедупликация файлов (и частей файлов ), версий и ветвей. Это особенно полезно, если вам нужно сделать резервную копию более чем одной машины или нескольких моментальных снимков ВМ.
- Можно добавить коды исправления ошибки -в архив, используя пар.2
- Простой доступ ко всему дереву резервных копий либо с помощью прямых команд, либо путем монтирования дерева как файловой системы FUSE
Предостережения, которые я нашел до сих пор:
- Все еще молод и находится в стадии альфа-тестирования (текущая версия 0.x)
- Требуется Python 2, так что это не совсем легко с точки зрения зависимостей
bupиспользует блокировку файла -в папке архива. Это означает, что файловая система, в которой размещается архив, должна поддерживать блокировку файла -. Это может быть проблема с общими ресурсами SMB. (Однако NFS работает.)- Резервное копирование на удаленные хосты или с них (через
ssh)требует установкиbup. - Для ваших имен резервных копий (, которые являются ветвями Git ), у вас может возникнуть соблазн использовать что-то, содержащее косую черту(
/). Дляgitэто не проблема.ноbup lsсмущается ими, так что не делайте этого. (Вы можете изменить название ветки с помощью подходящей командыgit branch -m, если вас это укусит.)
В дополнение ко всем отличным решениям, представленным выше, у меня есть еще один подход. Поскольку вы не упомянули используемую файловую систему, я предполагаю, что вы не используете zfs или btrfs. Эти файловые системы имеют встроенные -возможности для создания моментальных снимков, которые не являются копиями всей файловой системы, а только инкрементами. Типичным подходом был бы такой:
- Создайте файловую систему 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
`