OpenNET: статья - Управление каталогом /etc с использованием tar и git (git cvs config tar)

Ключевые слова: git, cvs, config, tar, (найти похожие документы)
From: Anton Chernyshov Date: Mon, 3 Feb 2010 17:02:14 +0000 (UTC) Subject: Управление каталогом /etc с использованием tar и git Оригинал: http://kelerus.livejournal.com/14271.html Лицензия: Creative Commons Attribution-Noncommercial-Share Alike 3.0 License (CC-BY-NC-SA). Введение Директория /etc является одним из ключевых мест Linux-системы. Каждый, кто любит поэкспериментировать с системой, знает как часто бывает так: отредактируешь несколько конфигурационных файлов, а потом спустя день-два обнаруживается, что что-то перестало работать. И не каждый обладает такой прекрасной памятью, чтобы вспомнить какие файлы редактировал и что конкретно менял. Хорошая привычка сохранять оригинальные конфигурационные файлы перед их редактированием приходит обычно с опозданием :). Многие бывалые системные администраторы сталкивались с подобными проблемами. Поэтому назревает вопрос -- а есть ли такое средство, которое позволяло бы отслеживать изменения сразу в нескольких файлах, вело бы своеобразную историю изменений? Как следует из одной хорошей поговорки (авторство, к сожалению, не помню) "если у вас появилась идея как решить какую-то проблему, то в мире Linux ее уже скорее всего решили или работают над этим" ;). В данной статье приведены принципы, которые позволяют достичь если не 100% надежности (таких гарантий не даст никто), то уж 90% проблем решат точно. Git. Инициализация и работа с репозиторием Первым таким средством является популярный инструмент разработчиков -- git. Разработчикам часто приходится отслеживать изменения сразу во многих файлах, поэтому git умеет это делать легко и быстро. git написан самим [16]Линусом Торвальдсом для ведения разработки ядра Linux (и уж конечно это не главное достоинство этой программы). Раньше для этого использовалось коммерческая программа Bit Keeper, за что Торвальдса постоянно упрекали. Когда ему надоели эти упреки, он написал git. В данной стать пойдет речь о том, как такое средство для разработки как git могут использовать обычные администраторы. git превращает директорию с файлами в [17]репозиторий, за состоянием которого он и будет следить. git умеет: * отслеживать изменения во всех файлах своего репозитория (естественно, включая файлы во вложенных директориях); * выполнять "коммиты", т. е. подтверждения изменения файлов (от слова commit), т. е. вести контрольные точки внесения изменений в конфигурационные файлы; * вести несколько ветвей (branches), которые можно будет независимо редактировать и переключаться между ними по мере необходимости. Далее я буду приводить все команды и их результат со своего домашнего компьютера, поэтому все изменения буду проводить над резервной копией директории /etc, находящейся в /root. Создание такой копии делается следующим образом: [root@localhost ~]# mkdir /root/etc [root@localhost ~]# cp -R /etc/* /root/etc/ Под термином "репозиторий" будет пониматься именно директория /etc, превращенная в репозиторий git. Кстати говоря, ознакомление с работой git, я рекомендую делать на резервной копии /etc, до тех пор пока вы не поймете назначения команд и то, что они делают. И только с приходом уверенности - переносить все на "живой" каталог /etc !!! В противном случае возможны непредсказуемые изменения файлов внутри /etc, цунами, торнадо, землетрясения и прочие неприятные последствия. Вы предупреждены! Перед созданием репозитория нужно создать список исключений, то есть список файлов, изменения которых git будет игнорировать. Сделать это нужно потому, что при нормальной работе системы некоторые файлы внутри /etc меняются сами. Перечень таких файлов определяется обычно используемым дистрибутивом. Обычно это файлы blkid.tab и mtab. Первый содержит служебную информацию об изменениях состояния блочных устройств, а второй - актуальную информацию о смонтированных файловых системах. Создание списка исключений делается созданием файла .gitignore в директории нашего будущего репозитория: root@localhost:~/etc# cat .gitignore blkid.tab mtab *[bB]ak asound.state Строчкой *[bB]ak я исключаю из-под контроля git файлы резервных копий, которые могут заканчиваться на bak или Bak. Последний часто меняется при изменении настроек громкости звука. Названия прочих файлов, которые следует исключить из-под контроля git, подскажет опыт эксплуатации системы (такие файлы будут часто самостоятельно меняться). Также можно проинформировать git о том, кто мы такие (необязательно), эта информация будет использоваться в качестве подписи при выполнении подтверждений изменений в директории: root@localhost:~# cat .gitconfig [user] name = Anton Chernyshov email = anton@localhost Для превращения какой-либо директории в репозиторий git, необходимо зайти в нее и выполнить следующие команды Для этого в своем домашнем каталоге нужно создать файл .gitconfig, следующего содержания: root@localhost:~/etc# cd /root/etc/ root@localhost:~/etc# git init Initialized empty Git repository in /root/etc/.git/ Команда git init создает директорию .git в нашем репозитории, которая будет содержать всю служебную информацию обо всех изменениях. Поскольку мы будем работать над каталогом /etc, а он содержит приватную информацию (самой критичной является наличие хешей паролей пользователей системы), то хорошим тоном будет сделать этот каталог недоступным для рядовых пользователей системы: root@localhost:~/etc# chmod o-rwx .git root@localhost:~/etc# ls -al | grep git drwxr-x--- 8 root root 4096 2009-12-27 17:57 .git Если все сделано правильно, то в правах доступа на директорию последние три символа будут "-", показывая, что никто кроме пользователя root и членов группы root не сможет зайти в данную директорию. Понятно, что глупо делать это сейчас, ведь мы работаем над резервной копией /etc внутри каталога /root, который и так не доступен пользователям системы. Однако об этом стоит не забывать при работе с реальным /etc. root@localhost:~/etc# git add . Команда git add . ставит в очередь на "коммит" все файлы, об изменении которых нет информации в репозитории. В данном случае это вообще все файлы, которые есть в /etc, включая все поддиректории со всеми их файлами, потому что репозиторий пока пуст. Коммитом (от английского слова commit) называется подтверждение изменений в файлах репозитория. Давайте выполним наш первый коммит: root@localhost:~/etc# git commit После ввода данной команды git попросит указать информацию о выполняемом коммите. Стесняться не стоит, нужно указать столько информации, сколько будет необходимо для того, чтобы потом вспомнить, какие именно изменения фиксирует данный коммит. Посмотреть информацию о коммитах можно выполнив следующую команду: [root@localhost ~/etc]# git log commit 0f97eb7b8f46bcdadf000bff1b12e5e29ac02a27 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 17:57:38 2009 +0300 .Инициализация репозитория В строке commit указан уникальный идентификатор коммита (это хеш, выполненный по алгоритму SHA). Далее указаны автор (тот, кто сделал коммит, см. выше про файл .gitconfig), дата и набранный на предыдущем шаге комментарий. Для ленивых предусмотрена опция -a, которая позволяет сделать коммит без предварительного выполнения команды git add. Ветви репозитория и отслеживание изменений Следующей полезной возможностью git является использование ветвей. Ветвь (branch) - это независимое состояние контролируемого репозитория. Редактирование одной ветви никак не влияет на другую, что и будет проиллюстрировано ниже. Использование ветвей необходимо тем, кто любит поэкспериментировать с системой. Можно иметь гарантированно работающую ветвь (в качестве нее можно оставить ветвь по умолчанию master) и ветвь для экспериментов (и назвать ее working). А затем, ту конфигурацию, которая показала себя работоспособной, переносить в первую. Создадим ветвь working: root@localhost:~/etc# git branch working root@localhost:~/etc# git branch * master working Команда git branch working создает ветвь working. git branch выводит список имеющихся ветвей. Звездочкой отмечена текущая ветвь master, которая автоматически создается при инициализации репозитория. Для переключения между ветвями нужно использовать команду git checkout: [root@localhost ~/etc]# git checkout working Switched to branch 'working' [root@localhost ~/etc]# git branch master * working Теперь звездочкой отмечена ветка working. Меняем один файл в директории и смотрим, что поменялось: [root@localhost ~/etc]# git diff diff --git a/exports b/exports index e69de29..9a0f871 100644 --- a/exports +++ b/exports @@ -0,0 +1,2 @@ +/srv/data 192.168.0.0/255.255.255.0 + Теперь при изменении любых файлов git нам будет показывать их изменения в таком вот виде, аналогичном выводу команды diff (за подробностями см. man diff). Для подтверждения данного изменения и внесения его в журнал нужно сделать следующее: [root@localhost ~/etc]# git add exports Этим мы ставим файл в очередь на коммит. Таким способом можно вносить информацию об изменениях отдельных файлов. Фиксируем информацию об изменениях: [root@localhost ~/etc]# git commit [working 4beda47] Экспортирование директории /srv/data через NFS 1 files changed, 2 insertions(+), 0 deletions(-) Смотрим информацию об изменениях: [root@localhost ~/etc]# git log commit 4beda47f709af7d8695a73bd1f69d3e319d34ba7 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:37:39 2009 +0300 .Экспортирование директории /srv/data через NFS commit 0f97eb7b8f46bcdadf000bff1b12e5e29ac02a27 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 17:57:38 2009 +0300 .Инициализация репозитория Следующая команда скажет чуть больше об изменениях: [root@localhost ~/etc]# git show commit 4beda47f709af7d8695a73bd1f69d3e319d34ba7 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:37:39 2009 +0300 .Экспортирование директории /srv/data через NFS diff --git a/exports b/exports index e69de29..9a0f871 100644 --- a/exports +++ b/exports @@ -0,0 +1,2 @@ +/srv/data 192.168.0.0/255.255.255.0 + Мы видим здесь информацию аналогичную сделанной ранее git diff (см. выше). По-умолчанию, git show показывает информацию о последнем коммите. Естественно, что можно попросить ее сделать это и для любого другого. Для этого в качестве параметра ей нужно передать идентификатор commit'а. Да, да, тот самый длинный SHA-хэш. Но не пугайтесь, его не нужно набирать целиком (эту же программу делали умные люди для таких же умных людей ;) ). Достаточно указать первые 5-6 символов (по сути достаточно, чтобы указанный идентфикатор коммита был уникальным). Проиллюстрируем это примером. Меняем еще один файл: [root@localhost ~/etc]# vim ~/etc/hosts Смотрим изменения: [root@localhost ~/etc]# git diff diff --git a/hosts b/hosts index 2556c5d..97d301d 100644 --- a/hosts +++ b/hosts @@ -3,3 +3,5 @@ ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 localhost 192.168.0.254 rivendale +192.168.0.35 rohan + Подтверждаем изменения: [root@localhost ~/etc]# git add hosts [root@localhost ~/etc]# git commit [working 63468c4] Добавление в сеть новых хостов 1 files changed, 2 insertions(+), 0 deletions(-) [root@localhost ~/etc]# git log commit 63468c4c541603e23d69dfb5ac43525f3eaab040 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:51:32 2009 +0300 .Добавление в сеть новых хостов commit 4beda47f709af7d8695a73bd1f69d3e319d34ba7 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:37:39 2009 +0300 .Экспортирование директории /srv/data через NFS commit 0f97eb7b8f46bcdadf000bff1b12e5e29ac02a27 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 17:57:38 2009 +0300 .Инициализация репозитория Теперь команда git show покажет нам информацию о последнем коммите: [root@localhost ~/etc]# git show commit 63468c4c541603e23d69dfb5ac43525f3eaab040 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:51:32 2009 +0300 .Добавление в сеть новых хостов diff --git a/hosts b/hosts index 2556c5d..97d301d 100644 --- a/hosts +++ b/hosts @@ -3,3 +3,5 @@ ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 localhost 192.168.0.254 rivendale +192.168.0.35 rohan + Посмотреть информацию о предыдущем коммите, можно следующей командой: [root@localhost ~/etc]# git show 4beda47 commit 4beda47f709af7d8695a73bd1f69d3e319d34ba7 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:37:39 2009 +0300 .Экспортирование директории /srv/data через NFS diff --git a/exports b/exports index e69de29..9a0f871 100644 --- a/exports +++ b/exports @@ -0,0 +1,2 @@ +/srv/data 192.168.0.0/255.255.255.0 + Выделение здесь мое, им я показал использованную часть идентификатора коммита. Как вариант, посмотреть и оценить общее состояние репозитория можно командой git status (я предварительно изменил файл resolv.conf): [root@localhost ~/etc]# git status # On branch working # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: resolv.conf # no changes added to commit (use "git add" and/or "git commit -a") Здесь мы видим, что git показывает нам изменившийся файл и говорит, что нужно сделать для выполнения коммита. Отмена внесенных изменений На всякий случай еще раз напомню, что git -- очень мощный инструмент и пользоваться им нужно аккуратно, поэтому прежде чем выполнять приведенные ниже операции, перед реальным применением рекомендую "потренироваться на кошках". Для отмены изменений которые еще не внесены в репозиторий (коммит не выполнялся и в репозитории есть изменения), нужно выполнить команду git checkout <имя_файла>. Команда git checkout . (с точкой) отменит вообще все изменения и репозиторий вернется в состояние, которое зафиксировал последний коммит (этот пример -- продолжение предыдущего): [root@localhost ~/etc]# git checkout . [root@localhost ~/etc]# git status # On branch working nothing to commit (working directory clean) Как мы видим, изменения, внесенные мной в файл resolv.conf, бесследно пропали. Изменения можно также откатывать и до определенных точек, включая все предыдущие. Чтобы было понятнее, я отредактирую два файла (resolv.conf и fstab) и выполню для этих изменений по коммиту: [root@localhost ~/etc]# git commit -m "Новый сетевой ресурс" fstab [working dc18de9] Новый сетевой ресурс 1 files changed, 2 insertions(+), 0 deletions(-) [root@localhost ~/etc]# git commit -m "Добавление в сеть нового DNS сервера" resolv.conf [working 02bc892] Добавление в сеть нового DNS сервера 1 files changed, 1 insertions(+), 8 deletions(-) [root@localhost ~/etc]# git log commit 02bc892b5fd8a40a063c06248268511ac3d1efb5 Author: Anton Chernyshov <anton@localhost.> Date: Tue Dec 29 23:04:36 2009 +0300 .Добавление в сеть нового DNS сервера commit dc18de9b99ec7ab661a3352491cd111c0a35e6ef Author: Anton Chernyshov <anton@localhost.> Date: Tue Dec 29 23:04:26 2009 +0300 .Новый сетевой ресурс commit 63468c4c541603e23d69dfb5ac43525f3eaab040 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:51:32 2009 +0300 .Добавление в сеть новых хостов <---------вывод команды обрезан для краткости-----------> Далее выполняем следующую команду: [root@localhost ~/etc]# git reset -p 63468 Такая команда заставляет git сгенерировать патчи для возврата к указанному состоянию (цифра -- это идентификатор коммита, к которому нужно вернуть состояние репозитория) и наложить их на соответствующие файлы. Говоря простым языком - git просто вернет содержимое данных файлов к указанному состоянию. Причем, перед каждым наложением патча git будет спрашивать подтверждение в таком вот виде: diff --git b/resolv.conf a/resolv.conf index 3142a1a..55117a9 100644 --- b/resolv.conf +++ a/resolv.conf @@ -1,2 +1,9 @@ -nameserver 192.168.0.254 +# Generated by NetworkManager + +# No nameservers found; try putting DNS servers into your +# ifcfg files in /etc/sysconfig/network-scripts like so: +# +# DNS1=xxx.xxx.xxx.xxx +# DNS2=xxx.xxx.xxx.xxx +# DOMAIN=lab.foo.com bar.foo.com Apply this hunk to index [y,n,q,a,d,/,s,e,?]? y Здесь опять указаны исходный и измененный файлы в формате вывода команды diff. Последней строчкой git спрашивает подтверждения указанной операции. y означает "yes", то есть "да", n - "no"/"нет". Знак вопроса выведет полную справку по возможным вариантам ответов. А вот вывод команды git log достаточно интересен в данном случае: [root@localhost ~/etc]# git log commit 02bc892b5fd8a40a063c06248268511ac3d1efb5 Author: Anton Chernyshov <anton@localhost.> Date: Tue Dec 29 23:04:36 2009 +0300 .Добавление в сеть нового DNS сервера commit dc18de9b99ec7ab661a3352491cd111c0a35e6ef Author: Anton Chernyshov <anton@localhost.> Date: Tue Dec 29 23:04:26 2009 +0300 .Новый сетевой ресурс commit 63468c4c541603e23d69dfb5ac43525f3eaab040 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:51:32 2009 +0300 .Добавление в сеть новых хостов <---------вывод команды обрезан для краткости-----------> Ничего не изменилось! Вывод команды git status восстанавливает статус-кво: [root@localhost ~/etc]# git status # On branch working # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: fstab # modified: resolv.conf # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: fstab # modified: resolv.conf # Что же произошло? git модифицировал содержимое каталога /etc на указанное состояние, но не изменил журнал коммитов. А это дает нам возможность вернуть все обратно. Делается это командой: [root@localhost ~/etc]# git checkout -p 02bc892 Дальше git нас спросит способом аналогичным выше о вносимых изменениях и если мы на все согласимся, то репозиторий вернется к состоянию, аналогичному до выполнения команды git reset: [root@localhost ~/etc]# git status # On branch working nothing to commit (working directory clean) Как вариант можно было бы вместо 02bc892 указать HEAD. Данное значение всегда указывает на самый последний коммит. Аналогичным способом можно отменить любой другой коммит на выбор. При этом git также не модифицирует свой журнал, позволяя нам выполнять отмену отмены коммитов :) (это полезно при поиске ошибок). Интересно себя поведет следующая команда: [root@localhost ~/etc]# git reset 63468 Unstaged changes after reset: M fstab M resolv.conf По сравнению с примером выше мы убрали ключ -p . При этом изменился журнал git (бесследно пропали записи о сделанных коммитах): [root@localhost ~/etc]# git log commit 63468c4c541603e23d69dfb5ac43525f3eaab040 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:51:32 2009 +0300 .Добавление в сеть новых хостов commit 4beda47f709af7d8695a73bd1f69d3e319d34ba7 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:37:39 2009 +0300 .Экспортирование директории /srv/data через NFS commit 0f97eb7b8f46bcdadf000bff1b12e5e29ac02a27 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 17:57:38 2009 +0300 .Инициализация репозитория А вот сами файлы при этом не изменились. Это логично, потому что мы не указали ключ -p, означающий patch (исправление). git status подтверждает это: [root@localhost ~/etc]# git status # On branch working # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: fstab # modified: resolv.conf # no changes added to commit (use "git add" and/or "git commit -a") Данная команда позволяет отменять неправильные коммиты, удаляя записи о них в журнале git, но не модифицируя сами файлы. После такой команды можно выполнить отмененные коммиты заново или сделать git checkout . , заодно отменив и изменения файлов: [root@localhost ~/etc]# git checkout . [root@localhost ~/etc]# git status # On branch working nothing to commit (working directory clean) Работа с ветвями репозитория А что насчет использования разных веток? К ним мы сейчас как раз вернемся. Напомню, что сейчас мы работали с ветвью working. Переключаемся обратно в master: [root@localhost ~/etc]# git checkout master Switched to branch 'master' [root@localhost ~/etc]# git log commit 0f97eb7b8f46bcdadf000bff1b12e5e29ac02a27 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 17:57:38 2009 +0300 .Инициализация репозитория А куда делись все наши изменения? А все просто -- их тут и не было. Мы работали с другой ветвью и вносили изменения туда. Можно проверить содержимое файлов, которые мы меняли ранее: [root@localhost ~/etc]# cat exports [root@localhost ~/etc]# Файл exports, как мы видим, пустой. Предположим мы решили, что изменения внесенные в ветвь working достаточно хорошо протестированы и их можно переносить в рабочую ветку: [root@localhost ~/etc]# git merge working Updating 0f97eb7..63468c4 Fast forward exports | 2 ++ hosts | 2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) Команда git merge производит слияние указанной ей в качестве параметров ветки с текущей, т.е команда git merge working переносит ее содержимое в текущую ветку. И, кстати говоря, еще показывает какие-именно файлы поменялись. [root@localhost ~/etc]# git log commit 63468c4c541603e23d69dfb5ac43525f3eaab040 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:51:32 2009 +0300 .Добавление в сети новых хостов commit 4beda47f709af7d8695a73bd1f69d3e319d34ba7 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 18:37:39 2009 +0300 .Экспортирование директории /srv/data через NFS commit 0f97eb7b8f46bcdadf000bff1b12e5e29ac02a27 Author: Anton Chernyshov <anton@localhost.> Date: Sun Dec 27 17:57:38 2009 +0300 .Инициализация репозитория Как мы видим, что теперь вывод команды git log для данной ветки аналогичен выводу данной команды для ветки working. Таким образом, используя приведенный набор команд можно достаточно легко вести историю изменений в директории /etc, самое главное не лениться и не забывать почаще вызывать для этого команду git. Да и экспериментировать с системой теперь можно гораздо смелее :). Ниже приведено резюме упомянутых команд git: Резюме команд: git init - создание репозитория в текущей директории git add filename - постановка файла filename в очередь на коммит. Если вместо filename указать точку, в очередь встанут все файлы, информации об изменении которых нет в репозиториях git commit - подтверждение сделанных изменений. git commit -a - то же, что и выше, плюс подтверждение удалений файлов. git branch branchname - создание ветви branchname в репозитории. git branch - вывод информации об имеющихся ветвях git checkout branchname - переключение на работу с ветвью branchname git checkout -p commit_id - отмена указанного коммита git reset -p commit_id - откат репозитория с конца до указанной точки, при этом все файлы репозитория меняются на указанную точку, журнал git не меняется git reset commit_id - удаление информации о коммитах с конца до указанной точки БЕЗ модификации файлов репозитория git log - вывести список коммитов. git show - показать информацию о последнем коммите git status - вывод информации о статусе репозитория (измененные, новые, удаленные файлы git merge branchname - производит перенос изменений из ветки branchname в текущую. git show commithash - покажет изменения подтвержденные последним коммитом. Подробности работы с git можно посмотреть в его официальной документации: man -k git , в директории /usr/share/doc/git и на официальном сайте Резервное копирование с помощью tar Для защиты директории /etc в качестве средства "второго эшелона" можно использовать хорошо известную команду tar. Сохраненные архивы файлов позволят восстановить несколько файлов, не редактируя их. Ниже приведен скрипт для выполнения регулярного резервного копирования директории /etc : #!/bin/bash # This file in UTF-8 encoding # Комментарием выше мы указываем используемую кодировку, # потому что для русского языка их существует очень много. # Задание директории для создания резервных копий BACKUP_DIR=/home/root/backup # Задаем количество резервных копий BACKUP_COUNT=10 # Проверяем существование директории для резервных копий # и если ее не существует - создаем ее if [ ! -d $BACKUP_DIR ]; then mkdir -p $BACKUP_DIR fi # Проверяем код выполнения предыдущей операции EXIT_STATUS=$? # Если код выполнения не равен нулю (операция НЕ завершилась # успешно),то завершаем работу скрипта if [ $EXIT_STATUS -ne 0 ]; then echo "Невозможно создать директорию" echo "Завершение работы" exit $EXIT_STATUS fi # Архивация директории /etc tar -cpjf $BACKUP_DIR/etc_$(date +%d_%b).tar.bz2 /etc # Удаление резервных копий возрастом старше указанного find $BACKUP_DIR/ -type f -ctime +$BACKUP_COUNT -delete # Возвращаем код успешного завершения работы операционной системе exit 0 Комментарии к скрипту: Переменная $? обычно хранит статус выполнения предыдущей команды. Если команда завершилась успешно, то он обычно равен нулю. Правила хорошего тона обычно требуют выполнять проверку успешного выполнения критически важных операций. В команде tar используется следующий набор опций tar -cpjf, означающих следующее: * c -- создание архива; * p -- сохранение при архивации прав доступа; * j -- для сжатия архива использовать архиватор bzip, как вариант можно было бы указать z для использования gzip; * f -- имя файла для создаваемого архива (данная опция должна быть последней). Полный список возможных опций можно посмотреть в man tar. В качестве имени архива мы используем следующее etc_$(date +%d_%b).tar.bz2 . Здесь мы для создания гарантированно разных имен файлов используем автоподстановку, применяя для этого команду date. Те опции, которые используются здесь, создают следующие имена файлов: [root@localhost /home/root]# ls -1 /home/root/backup etc_13_Dec.tar.bz2 etc_14_Dec.tar.bz2 Полный список возможных вариантов вывода команды date можно посмотреть в man date. Завершает скрипт команда find, используемая со следующими опциями: find $BACKUP_DIR/ -type f -ctime +$BACKUP_COUNT -delete Ее опции означают следующее: * она выполняет поиск в директории, заданной переменной $BACKUP_DIR ; * ищет обычные файлы - опция -type f * поиск файлов имеющих возраст более заданного количества дней задается опцией -ctime , например, опция -ctime +10 найдет файлы старше 10 дней * опция -delete говорит команде find, что найденные файлы следует удалять. Теперь еще можно сделать так, чтобы данные резервные копии отправлялись через ssh на другой хост сети, но это уже совсем отдельная тема и об этом мы поговорим позже. Теперь данный скрипт можно добавить как задание для cron, чтобы он выполнялся регулярно. Сделать это можно или через crontab -e (man crontab), или добавить его в каталог /etc/cron.daily.

2, Maxim Chirkov (ok), 21:27, 05/02/2010 [^] [^^] [^^^] [ответить]	+/–
>Вот статья оригинал :) >http://freeschool.altlinux.ru/?p=2546 Hет, в http://www.opennet.me/base/sys/etc_git.txt.html указана ссылка на верный оригинал, на freeschool.altlinux.ru перепечатка из блога http://kelerus.livejournal.com/, причем старой версии документа, о чем кстати в самом конце написано, см. пометку "Статья размещена в личном блоге Антона Чернышева".