http://www.ibm.com/developerworks/ru/library/l-backup/index.html?ca=drs-ru-0113
создать файл в нужно месте файл arh
на это файл нужно поставить флаг X, т.е. разрешить запуск
cd нужный каталог
создаем файл arh
touch ./arh
делаем исполняемым
chmod u+x ./arh
если нужно, то сменить владельца
chown новый_владелец ./arh
#!/bin/sh
tar czvf $1.$(date +%Y%m%d-%H%M%S).tgz $1
exit $?
Такой вариант будет создавать архив около папки, но нужно чтоб архивы были в отдельной папке и в одном месте ( и например чтоб до цифр было какое-то название, например www, если хранить архивы в тогда так /home/arhiv/ и чтоб имя начиналось с www, то так
#!/bin/sh
tar czvf /home/arhiv/www$(date +%Y%m%d-%H%M%S).tgz $1
exit $?
проверяем работу
путь_к_файлу_arh путь_к_тому_что_нужно_архивировать
например: /home/arhiv/arh /var/www
в каталоге /home/arhiv/
должен создаться файл с названием
wwwДАТА.tgz
чтоб автоматизировать, можно тогда это вставить в cron
/home/arhiv/arh /var/www
Показаны сообщения с ярлыком Архивирование. Показать все сообщения
Показаны сообщения с ярлыком Архивирование. Показать все сообщения
четверг, 15 января 2009 г.
пятница, 14 ноября 2008 г.
mysql
Как сделать копию базы MySQL
Существует программа mysqldump, позволяющая быстро и просто производить операции по созданию резервных копий баз MySQL. Также mysqldump дает возможность делать очень тонкие настройки для управления процессом создания резервных копий баз данных или отдельных таблиц. Можно сказать, что mysqldump - это основной инструмент, которым Вам придется пользоваться в том случае, если Вы будете делать backup MySQL.
Сразу возьмем простую задачу, которую будем решать с помощью mysqldump, и разберемся, что к чему. Есть хостинг, есть база данных DBNAME, которую выделил Вам хостинг-провайдер. Есть хост HOST, на котором размещен сервер MySQL, логин LOGIN к нему, порт PORT, на котором работает сервер, а также пароль PASS. Имея все эти данные, можно сделать dump (дамп, копию) базы DBNAME так (выполняем в unix shell):
> mysqldump -uLOGIN -PPORT -hHOST -pPASS DBNAME > dump.txt
После выполнения данной команды в файле dump.txt у нас будет копия MySQL-базы DBNAME. Это произойдет только в том случае, конечно, если все параметры Вы зададите верно, в соответствии с настройками своего хостинга. Сразу нужно сказать, что программа mysqldump производит вывод результатов прямо Вам на STDIN, то есть, на экран. Нужно перенаправлять вывод в какой-либо файл. Например, как в данном случае - " > dump.txt ". Если этого не сделать, а база большая, Вы получите на экран все те мегабайты информации, которые в ней содержатся.
Немного расскажем о том, что же делает mysqldump. Эта программа создает сценарий восстановления Ваших данных. То есть, вывод mysqldump - это не какие-то абстрактные и нечитаемые двоичные данные, а осмысленный текст сценария. Например, если в Вашей базе была таблица test, в которой было поле test2 с типом данных integer и одна-единственная запись "1111", то mysqldump создаст примерно такой сценарий:
# MySQL dump 8.14
#
# Host: HOST Database: DBNAME
#--------------------------------------------------------
# Server version 3.23.39-log
#
# Table structure for table 'test'
#
CREATE TABLE test (
test2 int(11) default NULL
) TYPE=MyISAM;
#
# Dumping data for table 'test2'
#
INSERT INTO test2 VALUES ('1111');
Таким образом, mysqldump "опишет" все Ваши таблицы и создаст INSERT-команды для восстановления данных в таблицах. Итак, мы перенаправляем вывод mysqldump в текстовый файл, который потом будем использовать для восстановления. Рассмотрим и этот процесс - воссоздание базы из резервной копии.
Для восстановления будем пользоваться стандартной программой mysql, которая входит в комплект поставки MySQL наряду с mysqldump. Допустим, у нас имеется backup в файле dump.txt. Нам нужно восстановить его в рабочую базу. Например, мы случайно удалили нашу базу данных, а теперь пытаемся исправить эту незадачу. Делаем так :
> mysql -uLOGIN -PPORT -hHOST -pPASS DBNAME < dump.txt
То есть, заставляем mysql-клиент соединиться с сервером и выполнить сценарий, который у нас имеется. После выполнения этой команды в Вашей базе появятся таблицы и данные из резервной копии. Учитывайте то, что данные будут просто восстанавливаться по сценарию из dump.txt. То есть, если таблицы, которые упоминаются в дампе базы, уже существуют и имеют другую структуру, тут явно возникнет ошибка. Просто посмотрите на сценарий и на рабочую базу и представьте, что Вы вручную выполняете команды из сценария. Если уверены, что все будет хорошо - смело восстанавливайте.
Рассмотрим более тонкие настройки mysqldump:
--databases позволяет сделать так, что mysqldump включит в сценарий восстановления команды CREATE DATABASE /*!33333 IF NOT EXISTS*/ DBNAME и USE DBNAME. Это позволит создавать рабочие базы "с нуля". То есть, без использования --databases подразумевается, что пользователь восстанавливает одну базу данных и явно указывает, куда нужно помещать восстанавливаемые данные. Если же backup создается с целью сделать полностью рабочую копию данных, например, на другом MySQL-сервере, то нужно использовать этот ключ;
--all-databases позволяет сделать копии всех баз данных, которые существуют на данном MySQL-сервере. Если же нужно сделать копии только некоторых баз, нужно просто указать их через пробел при вызове mysqldump из командной строки (см. выше);
Ключ --help. Программа mysqldump имеет множество версий. Посмотреть, какие возможности поддерживаются конкретно Вашей версией, можно с помощью этого ключа;
--add-drop-table - ключ, который заставит mysqldump добавлять в итоговый сценарий команду drop table перед созданием таблиц. Это позволит избежать некоторых ошибок при восстановлении базы из резервной копии. Конечно, нужно учитывать то, что таблицы, находящиеся в рабочей копии (если таблицы с таким же именем существуют в backup), перед восстановлением из резервной копии будут удалены из основной базы и пересозданы из backup;
--no-data. С помощью этого ключа можно быстро сделать копию структуры таблицы/баз без самих данных. Например, Вы создали сложную таблицу и хотели бы сохранить на будущее ее структуру, а сами данные, которые находятся в этой таблице, Вам в резервной копии не нужны;
--result-file=... - этот ключ можно использовать для перенаправления вывода в файл. Можно использовать обычное unix-перенаправление командой ">", а можно - вот этот ключ. Кому что нравится;
Кроме перечисленных ключей mysqldump имеет и еще некоторое количество очень полезных возможностей, которые Вы можете применять по обстоятельствам. Полная документация по mysqldump доступна на странице http://www.mysql.com/doc/m/y/mysqldump.html.
Еще один очень полезный совет по использованию mysqldump в хостинговой среде. Как правило, при использовании хостинга на пользователя налагаются некоторые ограничения. Например, нельзя занять больше некоторого количества физической памяти (RAM, ОЗУ). mysqldump по умолчанию помещает все полученные от MySQL-сервера данные в память, а потом записывает все это на диск. Соответственно, если провайдер дает Вам занять, например, 30Мб памяти, а база, копию которой Вы делаете с помощью mysqldump, занимает 50Мб, конечно, тут возникнет ошибка - mysqldump не сможет отработать корректно и завершится аварийно, о чем Вам сообщит. Чтобы "заставить" mysqldump писать данные сразу на диск, а не хранить их, пусть даже и временно, в памяти, используйте ключ --quick. Это решит проблему.
Автоматизация резервного копирования
Теперь подумаем, как бы нам автоматизировать процесс создания резервных копий базы данных. Итак, существует программа - cron. Она позволяет запускать процессы в указанное пользователем время или с определенной периодичностью. Сразу оговоримся - cron в общем случае существует только под Unix, так что, если Вы используете для хостинга ОС Windows, проконсультируйтесь со своим хостинг-провайдером о том, как лучше запускать процессы в нужное время. Да и вообще, пожалуй, этот пункт будет интересен только unix-пользователям.
В unix shell запускаем crontab -e и создаем такое правило запуска процесса создания копий базы:
0 0 * * * mysqldump -uLOGIN -PPORT -hHOST -pPASS DBNAME
| gzip -c > `date "+%Y-%m-%d"`.gz
Эта команда, запускаясь из cron в полночь (00:00) каждых суток, делает дамп Вашей базы DBNAME и архивирует его архиватором gzip в файл-архив с именем, соответствующим текущей дате. Например, если мы делаем dump 3 января 2002 года, имя файла с архивом будет 2002-01-03.gz. Для того, чтобы получить файлы, по именам которых можно удобно узнать дату их создания, мы используем команду date, которая является стандартной для всех unix-систем. Эта команда позволяет задавать произвольный формат вывода даты, что мы и использовали - date "+%Y-%m-%d". Мы поместили эту команду в обратные одинарные кавычки (backticks), что в unix shell заставляет вставить в команду (утрируя) результат выполнения другой команды.
Сохраняем правило для cron и ждем результатов. Итак, каждый день мы будем иметь на диске заархивированную копию нашей базы данных. Можно быстро найти нужный архив по его названию и восстановить то, что испортилось, например. Кстати, если Вы хотите автоматизировать удаление старых архивов, попробуйте воспользоваться cron и командой find, которая обычно есть в unix. Запуская периодически find ~/каталог-с-архивами -name "*.gz" -mtime +7, Вы будете удалять архивы, которые "старше" семи дней. Прочитайте документацию по find - она доступна по команде man find в unix shell.
Если у Вас есть машина, постоянно подключенная к интернет, можно так же по cron копировать созданный Вами backup на нее. Конечно, провайдерская хостинг-машина - это очень надежная штука. Однако, как говорится, "береженого Бог бережет". Старая как мир истина в определенных условиях может и Вам помочь. Используйте для копирования на другую машину команды ftp и scp. Добавьте их запуск в cron. Если Ваша машина поддерживает соединение по протоколу ssh, используйте secure copy клиент для копирования файлов - scp. Читайте документацию по этой команде в man-странице man scp. Примерный запуск: scp 2002-01-03.gz : - закачиваем файл 2002-01-03.gz на машину your.host.ru авторизовавшись там под логином login.
Существует программа mysqldump, позволяющая быстро и просто производить операции по созданию резервных копий баз MySQL. Также mysqldump дает возможность делать очень тонкие настройки для управления процессом создания резервных копий баз данных или отдельных таблиц. Можно сказать, что mysqldump - это основной инструмент, которым Вам придется пользоваться в том случае, если Вы будете делать backup MySQL.
Сразу возьмем простую задачу, которую будем решать с помощью mysqldump, и разберемся, что к чему. Есть хостинг, есть база данных DBNAME, которую выделил Вам хостинг-провайдер. Есть хост HOST, на котором размещен сервер MySQL, логин LOGIN к нему, порт PORT, на котором работает сервер, а также пароль PASS. Имея все эти данные, можно сделать dump (дамп, копию) базы DBNAME так (выполняем в unix shell):
> mysqldump -uLOGIN -PPORT -hHOST -pPASS DBNAME > dump.txt
После выполнения данной команды в файле dump.txt у нас будет копия MySQL-базы DBNAME. Это произойдет только в том случае, конечно, если все параметры Вы зададите верно, в соответствии с настройками своего хостинга. Сразу нужно сказать, что программа mysqldump производит вывод результатов прямо Вам на STDIN, то есть, на экран. Нужно перенаправлять вывод в какой-либо файл. Например, как в данном случае - " > dump.txt ". Если этого не сделать, а база большая, Вы получите на экран все те мегабайты информации, которые в ней содержатся.
Немного расскажем о том, что же делает mysqldump. Эта программа создает сценарий восстановления Ваших данных. То есть, вывод mysqldump - это не какие-то абстрактные и нечитаемые двоичные данные, а осмысленный текст сценария. Например, если в Вашей базе была таблица test, в которой было поле test2 с типом данных integer и одна-единственная запись "1111", то mysqldump создаст примерно такой сценарий:
# MySQL dump 8.14
#
# Host: HOST Database: DBNAME
#--------------------------------------------------------
# Server version 3.23.39-log
#
# Table structure for table 'test'
#
CREATE TABLE test (
test2 int(11) default NULL
) TYPE=MyISAM;
#
# Dumping data for table 'test2'
#
INSERT INTO test2 VALUES ('1111');
Таким образом, mysqldump "опишет" все Ваши таблицы и создаст INSERT-команды для восстановления данных в таблицах. Итак, мы перенаправляем вывод mysqldump в текстовый файл, который потом будем использовать для восстановления. Рассмотрим и этот процесс - воссоздание базы из резервной копии.
Для восстановления будем пользоваться стандартной программой mysql, которая входит в комплект поставки MySQL наряду с mysqldump. Допустим, у нас имеется backup в файле dump.txt. Нам нужно восстановить его в рабочую базу. Например, мы случайно удалили нашу базу данных, а теперь пытаемся исправить эту незадачу. Делаем так :
> mysql -uLOGIN -PPORT -hHOST -pPASS DBNAME < dump.txt
То есть, заставляем mysql-клиент соединиться с сервером и выполнить сценарий, который у нас имеется. После выполнения этой команды в Вашей базе появятся таблицы и данные из резервной копии. Учитывайте то, что данные будут просто восстанавливаться по сценарию из dump.txt. То есть, если таблицы, которые упоминаются в дампе базы, уже существуют и имеют другую структуру, тут явно возникнет ошибка. Просто посмотрите на сценарий и на рабочую базу и представьте, что Вы вручную выполняете команды из сценария. Если уверены, что все будет хорошо - смело восстанавливайте.
Рассмотрим более тонкие настройки mysqldump:
--databases позволяет сделать так, что mysqldump включит в сценарий восстановления команды CREATE DATABASE /*!33333 IF NOT EXISTS*/ DBNAME и USE DBNAME. Это позволит создавать рабочие базы "с нуля". То есть, без использования --databases подразумевается, что пользователь восстанавливает одну базу данных и явно указывает, куда нужно помещать восстанавливаемые данные. Если же backup создается с целью сделать полностью рабочую копию данных, например, на другом MySQL-сервере, то нужно использовать этот ключ;
--all-databases позволяет сделать копии всех баз данных, которые существуют на данном MySQL-сервере. Если же нужно сделать копии только некоторых баз, нужно просто указать их через пробел при вызове mysqldump из командной строки (см. выше);
Ключ --help. Программа mysqldump имеет множество версий. Посмотреть, какие возможности поддерживаются конкретно Вашей версией, можно с помощью этого ключа;
--add-drop-table - ключ, который заставит mysqldump добавлять в итоговый сценарий команду drop table перед созданием таблиц. Это позволит избежать некоторых ошибок при восстановлении базы из резервной копии. Конечно, нужно учитывать то, что таблицы, находящиеся в рабочей копии (если таблицы с таким же именем существуют в backup), перед восстановлением из резервной копии будут удалены из основной базы и пересозданы из backup;
--no-data. С помощью этого ключа можно быстро сделать копию структуры таблицы/баз без самих данных. Например, Вы создали сложную таблицу и хотели бы сохранить на будущее ее структуру, а сами данные, которые находятся в этой таблице, Вам в резервной копии не нужны;
--result-file=... - этот ключ можно использовать для перенаправления вывода в файл. Можно использовать обычное unix-перенаправление командой ">", а можно - вот этот ключ. Кому что нравится;
Кроме перечисленных ключей mysqldump имеет и еще некоторое количество очень полезных возможностей, которые Вы можете применять по обстоятельствам. Полная документация по mysqldump доступна на странице http://www.mysql.com/doc/m/y/mysqldump.html.
Еще один очень полезный совет по использованию mysqldump в хостинговой среде. Как правило, при использовании хостинга на пользователя налагаются некоторые ограничения. Например, нельзя занять больше некоторого количества физической памяти (RAM, ОЗУ). mysqldump по умолчанию помещает все полученные от MySQL-сервера данные в память, а потом записывает все это на диск. Соответственно, если провайдер дает Вам занять, например, 30Мб памяти, а база, копию которой Вы делаете с помощью mysqldump, занимает 50Мб, конечно, тут возникнет ошибка - mysqldump не сможет отработать корректно и завершится аварийно, о чем Вам сообщит. Чтобы "заставить" mysqldump писать данные сразу на диск, а не хранить их, пусть даже и временно, в памяти, используйте ключ --quick. Это решит проблему.
Автоматизация резервного копирования
Теперь подумаем, как бы нам автоматизировать процесс создания резервных копий базы данных. Итак, существует программа - cron. Она позволяет запускать процессы в указанное пользователем время или с определенной периодичностью. Сразу оговоримся - cron в общем случае существует только под Unix, так что, если Вы используете для хостинга ОС Windows, проконсультируйтесь со своим хостинг-провайдером о том, как лучше запускать процессы в нужное время. Да и вообще, пожалуй, этот пункт будет интересен только unix-пользователям.
В unix shell запускаем crontab -e и создаем такое правило запуска процесса создания копий базы:
0 0 * * * mysqldump -uLOGIN -PPORT -hHOST -pPASS DBNAME
| gzip -c > `date "+%Y-%m-%d"`.gz
Эта команда, запускаясь из cron в полночь (00:00) каждых суток, делает дамп Вашей базы DBNAME и архивирует его архиватором gzip в файл-архив с именем, соответствующим текущей дате. Например, если мы делаем dump 3 января 2002 года, имя файла с архивом будет 2002-01-03.gz. Для того, чтобы получить файлы, по именам которых можно удобно узнать дату их создания, мы используем команду date, которая является стандартной для всех unix-систем. Эта команда позволяет задавать произвольный формат вывода даты, что мы и использовали - date "+%Y-%m-%d". Мы поместили эту команду в обратные одинарные кавычки (backticks), что в unix shell заставляет вставить в команду (утрируя) результат выполнения другой команды.
Сохраняем правило для cron и ждем результатов. Итак, каждый день мы будем иметь на диске заархивированную копию нашей базы данных. Можно быстро найти нужный архив по его названию и восстановить то, что испортилось, например. Кстати, если Вы хотите автоматизировать удаление старых архивов, попробуйте воспользоваться cron и командой find, которая обычно есть в unix. Запуская периодически find ~/каталог-с-архивами -name "*.gz" -mtime +7, Вы будете удалять архивы, которые "старше" семи дней. Прочитайте документацию по find - она доступна по команде man find в unix shell.
Если у Вас есть машина, постоянно подключенная к интернет, можно так же по cron копировать созданный Вами backup на нее. Конечно, провайдерская хостинг-машина - это очень надежная штука. Однако, как говорится, "береженого Бог бережет". Старая как мир истина в определенных условиях может и Вам помочь. Используйте для копирования на другую машину команды ftp и scp. Добавьте их запуск в cron. Если Ваша машина поддерживает соединение по протоколу ssh, используйте secure copy клиент для копирования файлов - scp. Читайте документацию по этой команде в man-странице man scp. Примерный запуск: scp 2002-01-03.gz : - закачиваем файл 2002-01-03.gz на машину your.host.ru авторизовавшись там под логином login.
суббота, 3 мая 2008 г.
Резервное копирование с помощью архиватора RAR на сервере Windows 2003.
http://phorum.key.ru/viewtopic.php?f=16&t=21224
Резервное копирование с помощью архиватора RAR на сервере Windows 2003.
Документ создан: 28 апреля 2005 г.
Последняя редакция: 28 апреля 2005 г.
Технология внедрена: февраль-март 2005 г.
Источники.
Справка по архиватору RAR
Цель.
Обеспечить ежедневное резервное копирование файлов на сервере с возможностью быстрого восстановления отдельных файлов и каталогов. Также, необходимо, обеспечить возможность записи резервных копий на доступные носители (например, DVD-ROM).
Основные принципы.
Принципов не много: максимально надёжно, быстро и дёшево.
Краткий обзор имеющихся средств.
Так как целью является максимально снизить затраты на приобретение ПО и максимально увеличить скорость развёртывания, я не буду искать существующие комплексы резервного копирования, а возьму то, что есть «под рукой».
А под рукой у меня есть только встроенное в Windows 2003 средство ntbackup, которое зарекомендовало себя, как абсолютно непригодное для автоматического бэкапа пользовательских файлов, по причине регулярных сбоев, случаев невозможности восстановить файлы и отсутствием средств сжатия и разбиения резервных копий, для последующей записи на DVD.
Вторым средством, оказавшимся «под рукой» был всеми любимый RAR, который подходил по всем параметрам, но не имел графического интерфейса для организации бэкапа. А он нам нужен? Этот граф. интер. – подумал я. Настоящему сис.админу нужна только командная строка, которая как раз имеется. Вот о ней, а вернее о параметрах rar.exe мы и поговорим.
Идеология.
Идея такова: написать небольшой .cmd файл, который поставить в scheduler для ежедневного запуска. Создать специальную папку на дополнительном винчестере, куда складывать файлы резервных копий. Для наглядности и быстрого поиска нужного файла имена файлам давать следующим образом: год-месяц-день. Например: 2005-04-28 .rar
Реализация.
Собственно в .cmd файл добавить следующую строку:
"c:\Program files\WinRAR\rar" a -ag+YYYY-MM-DD -ac -ep2 -ilogG:\BackUp\backupERR.log -m5 -os -ow -r -rr15p -v4400m -t -y G:\BackUp\ @G:\BackUp\backupRAR.lst
Теперь пояснение.
После установки архиватора WinRar, в папке по-умолчанию, кроме файла winrar.exe у нас есть ещё файл rar.exe – это архиватор командной строки, его и будем использовать.
Команда “a” – означает создание нового архива, далее с префиксом “-” идут ключи.
Ключи:
-ag+YYYY-MM-DD – указывает, что к имени файлов *.rar будет добавлена строка с текущей датой, у нас получиться вот так: 2005-04-28.rar
-ac
указывает, что после архивации у файлов будет снят атрибут "Архивный". В принципе можно и без этого, но так правильнее %-)
-ep2
сохранять при архивировании полные пути файлов, то есть в архиве у Вас будет не каша, а такая же структура каталогов, как и на диске. Искать файлы в архиве так, значительно удобней.
-ilogG:\BackUp\backupERR.log
если возникнут ошибки, в этот файл они будут записаны. Если ошибок нет – то и файла этого не будет.
-m5
указывает степень сжатия.(–m0 без сжатия), я указал максимальную.
-os
сохранять потоки NTFS, долго объяснять. Короче, если у Вас файловая система NTFS, этот ключ лучше оставить. Надеюсь у Вас сервер не на FAT 32? ;-)
-ow
cохранять информацию о правах доступа к файлу при архивации и восстанавливать ее при извлечении. Так как у меня вполне налаженная система прав доступа, восстанавливать её всю заново в ручную было бы огромной проблемой, поэтому очень хорошо, что в rar есть такая функция.
-r
рекурсивная обработка подкаталогов. Будут архивироваться все вложенные папки и файлы, иначе только указанный Вами каталог.
-rr15p
добавить информацию для восстановления. Если некоторые биты в архивах будут повреждены, есть шанс эти биты восстановить и не потерять весь архивный файл. Чем больше информации для восстановления, тем больше шанс не потерять бэкап. Я указал размер добавляемой информации для восстановления - 15%(15p) от объёма архива. На практике эту функцию мне проверять не приходилось. Так что, хотите оставляйте этот ключ, хотите нет. Я оставил. Пусть будет. Так. На всякий случай.
-v4400m
максимальный размер одного тома. Получившийся архив будет разбиваться на несколько кусков, размер этих кусков мы и указываем. Так как размер стандартного DVD – 4,7 Gb, то значение должно быть около этих 4,7 Gb. Опытным путем было получен размер файлов, при котором один файл гарантированно влезет на один DVD – это 4400 Mb.
-t
протестировать файлы после архивирования. Ну что тут ещё пояснять, заархивировали – надо проверить.
-y
на любые вопросы rar будем отвечать «ДА»
С ключами всё, далее идёт указание папки, куда будут записываться архивные файлы, например: G:\BackUp\
А вот на параметре @G:\BackUp\backupRAR.lst остановимся особо.
Вообще говоря, это список файлов(папок), подлежащий архивированию. Если у Вас только одна папка, которую надо сохранять, вместо этого списка можете указать её, у меня же надо было архивировать несколько папок в разных местах диска. Поэтому я не стал их писать все в командную строку, а поместил список этих папок в отдельный файл, а ссылку на этот файл указал после значка @.
Список строится так: одна строка – одна папка. Заковычевать пути не нужно.
Важно: если у Вас есть русские буквы в названии папок, обязательно указывайте их в файле в DOS кодировке, иначе rar их не увидит и будет ругаться: File Not Found.
Ну, вот и всё. Для быстрого извлечения отдельных файлов из архива я использую уже не rar.exe, а WinRAR.exe - быстро и удобно. Открыл архивный файл, пометил что извлекать, указал куда и всё. Файл восстановлен. Запись на болванки DVD рекомендуется делать не реже раза в месяц. К сожалению, записывать придётся вручную, потому как процес автоматической подачу следующей болванки и выемки уже записанной я пока не придумал :-)
Удачи. И не угробьте случайно сервер. Потому как я за это отвечать не намерен.
_________________
Создать можно все. Вопрос только во времени, желании и средствах...
Но не всё, созданное тобой - окупится!
Резервное копирование с помощью архиватора RAR на сервере Windows 2003.
Документ создан: 28 апреля 2005 г.
Последняя редакция: 28 апреля 2005 г.
Технология внедрена: февраль-март 2005 г.
Источники.
Справка по архиватору RAR
Цель.
Обеспечить ежедневное резервное копирование файлов на сервере с возможностью быстрого восстановления отдельных файлов и каталогов. Также, необходимо, обеспечить возможность записи резервных копий на доступные носители (например, DVD-ROM).
Основные принципы.
Принципов не много: максимально надёжно, быстро и дёшево.
Краткий обзор имеющихся средств.
Так как целью является максимально снизить затраты на приобретение ПО и максимально увеличить скорость развёртывания, я не буду искать существующие комплексы резервного копирования, а возьму то, что есть «под рукой».
А под рукой у меня есть только встроенное в Windows 2003 средство ntbackup, которое зарекомендовало себя, как абсолютно непригодное для автоматического бэкапа пользовательских файлов, по причине регулярных сбоев, случаев невозможности восстановить файлы и отсутствием средств сжатия и разбиения резервных копий, для последующей записи на DVD.
Вторым средством, оказавшимся «под рукой» был всеми любимый RAR, который подходил по всем параметрам, но не имел графического интерфейса для организации бэкапа. А он нам нужен? Этот граф. интер. – подумал я. Настоящему сис.админу нужна только командная строка, которая как раз имеется. Вот о ней, а вернее о параметрах rar.exe мы и поговорим.
Идеология.
Идея такова: написать небольшой .cmd файл, который поставить в scheduler для ежедневного запуска. Создать специальную папку на дополнительном винчестере, куда складывать файлы резервных копий. Для наглядности и быстрого поиска нужного файла имена файлам давать следующим образом: год-месяц-день. Например: 2005-04-28 .rar
Реализация.
Собственно в .cmd файл добавить следующую строку:
"c:\Program files\WinRAR\rar" a -ag+YYYY-MM-DD -ac -ep2 -ilogG:\BackUp\backupERR.log -m5 -os -ow -r -rr15p -v4400m -t -y G:\BackUp\ @G:\BackUp\backupRAR.lst
Теперь пояснение.
После установки архиватора WinRar, в папке по-умолчанию, кроме файла winrar.exe у нас есть ещё файл rar.exe – это архиватор командной строки, его и будем использовать.
Команда “a” – означает создание нового архива, далее с префиксом “-” идут ключи.
Ключи:
-ag+YYYY-MM-DD – указывает, что к имени файлов *.rar будет добавлена строка с текущей датой, у нас получиться вот так: 2005-04-28.rar
-ac
указывает, что после архивации у файлов будет снят атрибут "Архивный". В принципе можно и без этого, но так правильнее %-)
-ep2
сохранять при архивировании полные пути файлов, то есть в архиве у Вас будет не каша, а такая же структура каталогов, как и на диске. Искать файлы в архиве так, значительно удобней.
-ilogG:\BackUp\backupERR.log
если возникнут ошибки, в этот файл они будут записаны. Если ошибок нет – то и файла этого не будет.
-m5
указывает степень сжатия.(–m0 без сжатия), я указал максимальную.
-os
сохранять потоки NTFS, долго объяснять. Короче, если у Вас файловая система NTFS, этот ключ лучше оставить. Надеюсь у Вас сервер не на FAT 32? ;-)
-ow
cохранять информацию о правах доступа к файлу при архивации и восстанавливать ее при извлечении. Так как у меня вполне налаженная система прав доступа, восстанавливать её всю заново в ручную было бы огромной проблемой, поэтому очень хорошо, что в rar есть такая функция.
-r
рекурсивная обработка подкаталогов. Будут архивироваться все вложенные папки и файлы, иначе только указанный Вами каталог.
-rr15p
добавить информацию для восстановления. Если некоторые биты в архивах будут повреждены, есть шанс эти биты восстановить и не потерять весь архивный файл. Чем больше информации для восстановления, тем больше шанс не потерять бэкап. Я указал размер добавляемой информации для восстановления - 15%(15p) от объёма архива. На практике эту функцию мне проверять не приходилось. Так что, хотите оставляйте этот ключ, хотите нет. Я оставил. Пусть будет. Так. На всякий случай.
-v4400m
максимальный размер одного тома. Получившийся архив будет разбиваться на несколько кусков, размер этих кусков мы и указываем. Так как размер стандартного DVD – 4,7 Gb, то значение должно быть около этих 4,7 Gb. Опытным путем было получен размер файлов, при котором один файл гарантированно влезет на один DVD – это 4400 Mb.
-t
протестировать файлы после архивирования. Ну что тут ещё пояснять, заархивировали – надо проверить.
-y
на любые вопросы rar будем отвечать «ДА»
С ключами всё, далее идёт указание папки, куда будут записываться архивные файлы, например: G:\BackUp\
А вот на параметре @G:\BackUp\backupRAR.lst остановимся особо.
Вообще говоря, это список файлов(папок), подлежащий архивированию. Если у Вас только одна папка, которую надо сохранять, вместо этого списка можете указать её, у меня же надо было архивировать несколько папок в разных местах диска. Поэтому я не стал их писать все в командную строку, а поместил список этих папок в отдельный файл, а ссылку на этот файл указал после значка @.
Список строится так: одна строка – одна папка. Заковычевать пути не нужно.
Важно: если у Вас есть русские буквы в названии папок, обязательно указывайте их в файле в DOS кодировке, иначе rar их не увидит и будет ругаться: File Not Found.
Ну, вот и всё. Для быстрого извлечения отдельных файлов из архива я использую уже не rar.exe, а WinRAR.exe - быстро и удобно. Открыл архивный файл, пометил что извлекать, указал куда и всё. Файл восстановлен. Запись на болванки DVD рекомендуется делать не реже раза в месяц. К сожалению, записывать придётся вручную, потому как процес автоматической подачу следующей болванки и выемки уже записанной я пока не придумал :-)
Удачи. И не угробьте случайно сервер. Потому как я за это отвечать не намерен.
_________________
Создать можно все. Вопрос только во времени, желании и средствах...
Но не всё, созданное тобой - окупится!
Подписаться на:
Сообщения (Atom)