- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
#!/bin/bash
echo Создание каталога...
if ! [ -d ./dump ]; then
mkdir ./dump
fi
currentdate=$(date +%F);
cd ./dump
echo Создание резервной копии основной базы данных...
pg_dump -U %логин% -f database.dump
echo Создание архива...
lzma -9vc database.dump > $currentdate.lzma
echo Удаление временных файлов...
rm -rf database.dump
echo Создание резервной копии завершено.
Follow us!
нахера создавать папку по относительному пути?
а) имеется тут же файл .pgpass с логинами/паролями для доступа к БД
б) в заданиях cron'а стоит выполнение данного скрипта. Не от имени root же делать бэкапы.
же!
шта?
Что мешает на ходу сжимать, без временных файлов? pg_dump | xz > $currentdate.sql.xz
Раньше в один архив помещалось два дамба двух разных БД (одна для хранения инфы, одна для логов действий пользователей).
(pg_dump --blabla && pg_dump --blabla) | xz > $currentdate.sql.xz
И ещё: LZMA на уровне -9 будет отжирать уж слишком много памяти при сжатии при сомнительном профите.
Да, и /bin/bash - непортабельно. Тем более в скрипте всё равно нет ни одного башизма.
cd ~
if ! [ -d ./dump ]; then
mkdir ./dump
fi
currentdate=$(date +%F);
cd ./dump
echo Создание резервной копии основной базы данных...
pg_dump -U %логин% | xz -9e -z T 6 -v -F gz > $currentdate.gz
echo Создание резервной копии завершено.
Они же склеются в один файл... Потом расчленять придется при восстановлении, если нужен только один. Неудобно.
Это уже вопрос к ОПу, а не ко мне.
Судя по тому, что ОП выгружает дампы на диск - 146%, что он делал tar.xz.
http://ru.wikipedia.org/wiki/7-Zip
За что ж так Лемпеля?
Как бы это уже тоже устарело. systemd - это теперь наше все.
Кроме того, лучше делать архив так, чтобы он сразу же уничтожал незаархивированый файл. Можно приводить разные аргументы в пользу надежности разных сценариев, но, на практике, я сталкивался с ситуацией, когда бекап нельзя было сделать потому, что не хватало места, а чтобы запороть бекап при создании архива - ну это нужно, чтобы электричество отключили, или что-то такого плана.
Ну тогда уж пайп, как WGH советовал выше.
> а чтобы запороть бекап при создании архива - ну это нужно, чтобы электричество отключили
Если создавать архив под временным именем, а потом перемещать в нужную папку - шанс на фейл почти нулевой. Такую транзакцию на журналируемой фс хер убьешь даже отключением света. А если и убьется - то вместе с файловой системой.
P.S. Вот что самое главное - никогда не создавать бекап сразу поверх старого. Да и вообще, желательно его сливать куда-нибудь на ленточку или соседний сервак. Данные и их бекап на одном компе = ССЗБ.
2. Проверяй наличие свободного места!!! Например, что есть как минимум 20% места. Громко жалуйся на ошибки.
3. `mkdir` заменить на `mktemp -d`
4. `cd ./dump` - когда тебе важны данные всегда *ВСЕГДА* проверяй результат `cd`. Если где-то что-то обламалось и папка не существует, то ты будешь переписывать и удалять локальные файлы. (Это опять отсылка на использованию абсолютных путей.)
5. Про pg_dump | xz тебе уже расказали: когда можно, лучше избегать дергать файловую систему за зря.
6. Пользуйся `xz -2` - по компресси аналогично bzip2, но намного быстрее. Скорость бэкапа может и не самый важный критерий, но по моему опыту лучше сервак за зря не грузить. А если грузишь, то не надолго. Думай так: сбой может произойти час спустя как ты запустил бэкап. Быстрый бэкап уже закончит - медленый будет прерван. В первом случае у тебя уже есть с чего данные подымать. Во втором - данные только с прошлого дня.
7. Добавь `sync` в конце скрипта для пущей надежности.
8. Вывод бэкап скрипта шли самому себе на мыло. Например:
bash the_cool_backup.sh | mail -s "Backup output from $(date +%F)" [email protected]
Плюс добась где-нибудь вывод того сколько времени комманды заняли (добавь `time`). Низкая скорость часто есть признак проблем.
... причем на том серваке, на который этот архив приземляется.
главное что бы архивы лились на другой диск, а не на тот же диск где и сама база лежит.
....
и еще более главное, это раз в месяц старые бэкапы проверять на целостность. потому что современные диски имеют тэнденцию сыпатся почти в рандомных местах.
я собственно только по этой причине свои бэкапы и архивирую. как правило с самой низкой компресией (но не store) что бы целостность потом можно было проверить. (некоторые архиваторы для store даже чексум не генерят.)
Причем незаметно, доо.
>как правило с самой низкой компресией (но не store) что бы целостность потом можно было проверить.
А что мешает отдельно чексуммы генерить?
Зачем? Архиватор уже все делает за меня. Ну и в добавок, если можно, слегка архивирует.
И в каждую ось уже все проинтегрировано из коробки: открываешь архив, нажимаешь кнопку "тест", готово.
навороченые хэши нужны только если тебе нужна крипто-сильная подпись, что бы кто-то данные не подменил.
я честно говоря начал архивами пользоватся только потому что мне нужно было бэкапить в начале кучи файлов. оно просто и на само деле удобно, почему ничего другого и не искал.
хотя с точки зрения физики любую инфу можно восстановить.
кроме попавшей в чд
Так что вся надежда на распределённость бекапа. В чем неплохо помогают облака.
P.S.: http://tjournal.ru/paper/block-school-for-nothing
И? А винт можно уронить на пол, комп могут украсть или изъять, флешку постирают вместе со штанами, а распечатку съест кот.
Просто не надо держать все яйца в одной корзине, вот и всё.
насколько я помню в других местах нашей бренной вселенной с точки зрения физики информация, как и энергия, не исчезает
На самом деле нет.
Ученые недавно изобрели облачный /dev/null в котором любая ваша информация гарантированно исчезнет.
Ну а насчёт исчезновения энергии в черной дыре - это и вовсе бред, её масса ведь увеличится.
Выходит, по теории доктора Кегдана, информация всё ещё доступна, поскольку она всё ещё в нашей вселенной. Ну а что достать кто-то не может - так это проблемы ниасиляторов.
Знание нескольких японских слов и Аска на аватарке еще не делают меня отаку ;)
http://vk.com/video86875430_145736276
У меня cron это сам делает. Достаточно перед записью написать MAILTO=...
Дампать лучше в custom формат: будет чуть меньше места
Используйте пайпы, чтобы не плодить временные файлы: foo | bzip2 > bar.bz