Полезни скриптове

[afx]

Предлагам в тази темичка да публикуваме някакви полезни скриптчета чрез които ... улесняваме живота на клиентите ни пък и нашия собствен защото когато няма работа за системния администратор - значи той си е свършил добре работата

 

Преди няколко дни трябваше да измисля как да защитя информацията на едно файлово сървърче но... след известно време на умуване става ясно че RAID 1 дори и да може да те защити от форсмажорни ситуации (светкавици а у...) не предпазва от логическа и човешка грешка (прецакана файлова система или "случайно" изтрит файл). Затова просто написах няколко реда които да правят адекватен daily и weekly backup от единия твърд диск /store на друг - /backup

 

#!/bin/bash
#
# Daily sync script by afx - /etc/cron.daily/daily-rsync
#
rsync -ap /store/home/ /backup/daily/home/ &> /dev/null
rsync -ap /store/mail/ /backup/daily/mail/ &> /dev/null
rsync -ap /store/mysql/ /backup/daily/mysql/ &> /dev/null
rsync -ap /store/share/ /backup/daily/share/ &> /dev/null
echo 'daily-rsync: home, mail, mysql and share - synchronized on' `date` >> /root/server.log

#!/bin/bash
#
# Weelky archive script by afx - /etc/cron.weekly/weekly-archive
#
now=`date +%Y-%m-%d`
tar -czvf /backup/weekly/$now.tar.gz /backup/daily/* &> /dev/null
echo 'weekly-archive: /backup/daily archived to /backup/weekly on' `date` >> /root/server.log

 

Нищо сложно.. просто и ефективно Сега тряаа да изпукат всичките хард дискове едновременно или да се запали офиса.

[nassko]

....

rsync -ap /store/mysql/ /backup/daily/mysql/ &> /dev/null

......

 

Май е добра идея преди архивирането да се спре MySQL сървъра ...

[afx]

Май е добра идея преди архивирането да се спре MySQL сървъра ...

Хмм.. добре. Само ако ми кажеш защо .. за да съм по-спокоен

[Pisach]

Бекъпа не е така лесен както си го мислиш "Копирам всичко и спя спокойно". Много приложения изискват да бъдат спрени (особенно базаданните) за да стане читав бекъп.

На mySQL бекъп се прави с mysqldump, ето ти линк http://dev.mysql.com/doc/refman/5.0/en/backup.html.

Бекъпа е много отговорно нещо, хора могат да останат без работа от твоите съвети

[afx]

Хм да прав си принципно. Явно само файловете няма да свършат работа при mysql-а. Аз затова и споделих скриптчето със вас за да може евентуално да го доразвия с ваша помощ

Ок ще сменя реда за да прави mysqldump на всичко включително и на основната mysql база (нали там се пазеха user-ите все пак)

[notor1ous]

Без да съм експерт в областта или системен администратор, но с опит в "преместване" на бд-та и backup, смятам, че идеята на този скрипт не е добра.

Ако копираш само файловете няма да има съвместимост между различните версии на MySQL.

Back-up трябва да се направи на външен носител. Не е надеждно да се направи на другия хард, защото никой не може да гарантира, че при форсмажирни обстоятелства няма да заминат и двата харда.

Когато има бази с голяма информация в тях най-важното при копиране е да се направи така, че да не навреди на сървъра, т.е. операцията трябва да е нископриоритетна. rsync прави сравнение между файловете и след това копиране на различията между тях. При големи файлове това може да се окаже тежка операция. За този тип back-up според мен е по-добре да се прави отделна дир и да се ползва scp - по-бързо е.

Като цяло за мен най-добрия начин за back-up е чрез скрип от друга машина, която се вързва към дб-то на сървъра и генерира SQL (аналогично на mysqldump), който да записва на външен за сървъра хард или друго устройство. Трябва да се правят различни файлове за всеки ден и да следи историята на промените в базата, защото иначе няма смисъл от back-upa.

[Godfather]

По принцип варианта на бекъп с копирането на фаиловете без спиране на сървъра е възможен, но само ако предварително се LOCK-нат и FLUSH-нат съответните таблици и също така те са от типа MyISAM, ISAM (точно това прави популярния mysqlhotcopy скрипт като операцията е доста по-бърза от mysqldump). В случая на InnoDB таблици се използва mysqldump с някои допълнителни опции, които ускоряват restore операцията. По-добрият вариант е отделен бекъп сървър, на който върви MySQL в репликейшън режим (естествено, ако е необходимо създаването на "исторически" архив от ежедневни копия на базата например, тогава трябва репликацията трябва да се комбинира с mysqlhotcopy през определения интервал от време). Репликацията използва log-bin= опцията в my.cnf (или стартиране на демона с --log-bin опция) за създаване на т.нар binlog файл, който може да се използва и за възможно най-точен и цялостен restore. За съжаление клъстърните конфигурации не поддържат репликации до версия 5.0 (която е масовия вариант на продуктови машини в момента), но тази ценна функция е добавена в 5.1.

[vhristev]

Ето последния пост беше напълно смислен и мога да твърда ,че човека си разбира от работата.

Аз примерно правя дъмп и от 4.0 минах на 5.1 база данни като просто трябваше да се ъпдейтне парилите юзер дефиницята

mysqldump --opt -u user -pPASS Data_BASE > DB_data.sql

sled tova update pass users etc.

SET PASSWORD FOR 'USER'@'localhost' = OLD_PASSWORD('USER');

Без да спирам базата данни.

И аз съм мислил за репликация ,но просто допълноително 500Г нямам ,за да направя актуално работешт втори сървър просто правя бек ъп на базата.

 

И аз ползвам Рсинк + мое скриптче което запазва /etc /usr /boot + MBR + mysql dump-a и така се въртят на 3-ри сървъра.

 

С удоволствие бих се радвам за развитие по темата с бек ъпите варианти много просто е въпрос на конфигуриране и фирмена политика.

 

Поздрави

В.Христев

[Pisach]

Disaster Recovery е цяла наука вече.

На последната си работа правихме backup чрез Backup Tape Rotation. Всяка вечер базата се дъмпваше на лента и на сутринтта касетката се сменя....като доста често забравях да го правя . За да се избегнат такива ситуации има устройства с 7 касетки, като касетката се сменя автоматично. Optimizing Your Backup Tape Rotation Strategy Също така в понеделник правих запис на базата на ЦД и я пращах в центалата в София.

Много е важно бекъпите да не се съхраняват в същата сграда, защото при пожар или кражба всичко отива в /dev/null.....или пове да се съхраняват в огнеупорна каса....или поне на друг етаж .

В настоящата ми работа ползваме IBM Tivoli Storage Manager, където нещата са доста по сложни. Правят се инкрементал бекъпи през мрежата през определено време, пази се история pа 10 бекъпа на зад и т.н.

Подобен продукт е и Veritas NetBackup.

Цитат от Wikipedia

A few years earlier, during a fire at the headquarters of Credit Lyonnais, a major bank in Paris, system administrators ran into the burning building to rescue backup tapes because they didn't have offsite copies.

http://en.wikipedia.org/wiki/Backup

[dX]

..и тъй като се заговори за backup на mysql - ето едно скрипче което написах преди месеци за да си олесня работата

 

#!/bin/bash -e
##########################################################################
# Back up MySQL databases
## NikolaP @ SiteGround LLC
##########################################################################

echo "Starting backup at `date`"

username="DB_USER"
password="DB_PASS"
TIME_STAMP=`date "+%Y-%m-%d"`
BACKUP_DIR="$HOME/backups" && mkdir -p $BACKUP_DIR
KEEP_CLEAN="1"
IGNORE_DBS="test"

DB_LIST=`mysql -u$username -p$password -Bse 'show databases'`

echo "+ backing up the database"
for db in $DB_LIST; do
mysqldump -q -Q --opt -u$username -p$password $db | gzip -1 > $BACKUP_DIR/$TIME_STAMP--$db.sql.gz
echo " - $db"
done
echo " - done."

echo "Finished."
exit 0

 

..най-долу може да се допълни едно expect скрипче което да качва архивчетата на remote ftp сървър, или да използвате scp.. - зависи къде искате да си съхранявате backup-ите.

[lil_stenly]

Благодаря ти за скрипта !

Ще е полезен за игрален сървър !

Ще видим с какво ще е от полза !

А , може ли да се направи през remote машина да става бакъпа ако забие тази ... мойта ?

[dX]

Разбира се че може Ще трябва да модифицираш скрипта и да сложиш по един параметър --host на mysql mysqldump командите и не би трябвало да имаш проблеми.