Автоматическое резервное копирование

Собираюсь переезжать на выделенный сервер. Чем, как у куда делаете бэкапы?

46 комментариев

avatar
Феерический эпик фэйл ощущаю я…
avatar
isp манагером автоматически делаю бекап на www.selectel.ru/
avatar
Бэкап БД или файловой системы? Или все вместе? Если по отдельности — то снять дамп БД с текущего хостинга, создать новую БД с теми же параметрами на новом хостинге, залить дамп туда. Залить ФС и смотреть что получится.
avatar
а если просто — файлы tar.gz, базу mysqladmin'ом так-же в архив! Ну и доброй дорожки ж )
avatar
Давно использую вот такой bash скрипт.
Для бэкапа файлов можно раскомментировать соответствующую строчку.
Также пути к некоторым командам типа find могут отличаться в разных системах.
#!/bin/bash

MyUSER="user"       # USERNAME
MyPASS="password"   # PASSWORD
MyHOST="127.0.0.1"  # Hostname
DBName="dbname"     # Dbname

DEST="/..../backups"

# заносим в переменную DATE текущую дату
DATE=`/bin/date '+%Y.%m.%d'`

FILE="$DEST/$DBName"_"$DATE.sql.gz"

# оптимизация
mysqlcheck -u $MyUSER -p$MyPASS --auto-repair --check --optimize --all-databases >/dev/null 2>&1

# сохраняем дамп mysql
mysqldump -u $MyUSER -h $MyHOST -p$MyPASS $DBName | gzip -9 > $FILE

# архивируем все каталоги, кроме тех, в которых находится файл .noarchive
# /bin/tar -zcf PATH-TO-DIR-BACKUP/$DATE.backup.tar.gz --exclude-tag=.noarchive ./

# удаляем архивы, которым уже больше семи дней
/usr/bin/find $DEST -type f -name *.gz -atime +7 -exec rm -f \{\} \; >/dev/null 2>&1
avatar
Вы бэкапите на тот-же хост, где и сам ваш ресурс расположен? Оо
avatar
так зачастую быстрее. У нас раньше в обязательном порядке было хранить три копии бэкапа данных: 1 на текущем хосте (в случае если надо быстро ресторнуть бд или файлы) второй на удаленном сервере, третий удаленный с удаленного сервера.
avatar
Глупо хранить бэкап там-же, где и сам ресурс. Даже, я сомневаюсь назвать это бэкапом. По большей части пустая трата ресурсов, ну и может быть «защита» от случайного rm.
avatar
тут либо бакула, либо дампить на локальную машину, затем рсинкать на удаленные.
xtrabackup или mysqldump сразу на удаленную машину — это плохо. особенно, когда базы вырастают до 5-10 гигов
avatar
Собственно и я о том-же как-бы хотел сказать.
Пользуясь случаем наверно зарекомендую к прочтению mega.co.nz/#!m0QVSRzR!EpK3qDTEOlZhOJF0MQTF-xobeLQUClHcMS0mpyws4X0
avatar
смонтирован dropbox, по крону туда тарится mysqldump и копия сайта без uploads.
avatar
Для комплекта -
avatar
Ух ты, по ctrl+v отправилось

www.dropbox.com/install?os=lnx

Дропбокс для дебиана. Заводим аккаунт, получаем бесплатные 2Гб, монтируем, по желанию расшариваем бэкап-аккаунт с основным своим аккаунтом.
avatar
Мусклдампом вредно бекапить. Он блокирует таблицы. Лучше например хотя-бы xtrabackup.
А вообще, по человечески, так бакулу юзаем.
avatar
Мусклдампом вредно бекапить. Он блокирует таблицы.

вы просто не умеете его готовить

dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_single-transaction

вкратце: с ключом --single-transaction InnoDBшные таблицы не лочатся
avatar
Я какраз умею. Но на практике это ни к чему хорошему не приводит, особенно при большых базах и когда их не одна. mysqldump — Очень ресурсоёмкий.
avatar
А что значит блочатся? Эту базу потом не восстановить будет?

В примере приведенном в топике, чтобы без этой блокировки было нужно так изменить?

mysqldump -u $MyUSER -h $MyHOST -p$MyPASS $DBName --single-transaction | gzip -9 > $FILE
avatar
# архивируем все каталоги, кроме тех, в которых находится файл .noarchive
# /bin/tar -zcf PATH-TO-DIR-BACKUP/$DATE.backup.tar.gz --exclude-tag=.noarchive ./

Прописал путь до папки лс, но почему то не бэкапит.
avatar
С бекапом сайта разобрался, вопрос про --single-transaction в скрипте еще актуален
avatar
А что значит блочатся?
dev.mysql.com/doc/refman/5.1/en/lock-tables.html
avatar
Для БД юзаю sypex dumper — норм. Только рекаверить нужно им же.
avatar
У меня bash скрипт по крону вызывает mysqldump, жмет результат в tar.gz и посылает по почте на ящик google.com. Ну и контроль, чтоб локально лежали бэкапы только за неделю — остальное удаляется.
Всё это долго описывать, а на деле скрипт-файл даже до 10 строк не дотягивает. Пока база не очень большая в сжатом виде — этого хватит :) А там посмотрим.
avatar
Перебирайтесь на Амазон!

/usr/bin/ec2-consistent-snapshot --mysql --freeze-filesystem=/raid --region=eu-west-1 --description "RAID snapshot $(date +'%Y-%m-%d %H:%M:%S')" vol-xxxxxxx vol-xxxxxxx vol-xxxxxxx vol-xxxxxxx --aws-access-key-id=xxxxxxx --aws-secret-access-key=xxxxxxx --mysql-defaults-file=/etc/mysql/debian.cnf


+ для быстрых операций, дополнительные локальные дампы таблиц, через automysqlbackup.
avatar
Я хочу выразить две благодарности господину rsmike

Во-первых за совет про --single-transaction ( чтобы там не говорил господин ewden mysqldump является простым и надёжным решением для бэкапа БД, пока она не доросла до гигабайтных размеров — а до этого ещё дожить надо.

Во-вторых за прекрасную идею про Dropbox. Халявное облачное пространство, которое без больших усилий мы раздули до 4Gb и бэкапы которые автоматом синхронизируются туда, а затем оттуда на домашний десктоп — это просто шикарно.

Спасибо!
avatar
Можно еще яндекс диск подключить как davfs и туда тоже бэкапитьб, но сам так не делаю, я параноик, да и бесплатно 100 гигов под бэкапы дают.
avatar
Gmugra , Насколько у вас большая база? Сколько времени занимает процесс бэкапа/восстановления? А обращали внимание на затраченные ресурсы во время копирования?
Вообще да, бэкапить в дропбокс, яндекс.диск паранойя не позволяет. Можно конечно взять и зашифровать архив с бэкапом используя например тот-же GnuPG. Но тут опять-же, до поры до времени.
Ну и вообще ладно. Дело ваше, надеюсь со временем поймёте, что есть более классные и лёгкие инструменты по сравнению с mysqldump.
avatar
Не помню сколько в виде дата файлов база занимает точно, врать не буду, но больше 100Mb. SQL-Dump — ~40Mb. Создаётся mysqldump-ом за секунд 5. Работает дамп ежедненво глубокой ночью, когда на сайте всё равно никого нет, так что даже если это и локает какие то таблицы — никого не задевает. Чтобы эти пройессы хоть ккто загружали наш сервер я вообще увидеть не смог. Да и нечему там загружать. Даже теоритически. А ваши опасеня начет облачного хранилища мне совсем не понятны. Во-первых можно и шифровать, да. Во-вторых эти бэкапа синхронизиуреуются у нас оттуда на домашние компы очень даже быстро (от размера файла зафисит). Решенье классное -
avatar
Опасения — сервера чужого дяди. Кто знает, что чужому дяде в голову придёт. Без шифрования ну уж точно не доверил бы. С шифрованием, наверно, тоже, подумал хорошо бы, перед тем как делать.
Насчёт слить на дом. тачку, в принципе решений и других может быть не мало.
avatar
А гуглу вы тоже не доверяете? Всю почту зашифрованой шлёте? А хостеру своему? :) Dropbox это же не Вася Пупеин & co. Dropbox — огромный сервис, нужны там ваши бэкапы кому-то. Кроме того в области защиты данных они там тоже на самотёк не пускают www.dropbox.com/privacy#security
avatar
Не доверяю. Не юзаю их ГуглХром даже, а юзаю Хромиум. А почта, с ней уже работаем давно только через tls/ssl. А хостер, я практически сам себе хостер, и имею круглосуточный физический доступ ко всем своим серверам и т.п. И не надо мне приводить ссылку на их политику приватности. Написать в ней можно всё что угодно. Огромным, простите, он как раз стал и из-за кучи доверчивых халявщиков.
avatar
Ну что же, я хоть и удивлён но вашу позицию понял :).
avatar
Да, а что если к хранилищам дропбокса получат доступ третьи лица и сольют данные? Благо дело, в некоторых конторах шефы предусматривают это и запрещают на раз сотрудникам передавать служебные документы и т.п через подобные хранилища.
avatar
Вопрос во-первых в данных, конечно. В бэкапах нашего сайта, например, ничего особенно ценного для третьих лиц нет. Мы итак это всё публично в интернет выложили, собственно :)

Во-вторых вопрос доверия. Косяки бывают у всех. И у Dropbox того же был в 2010 году прецедент. Но это не повод уж совсем паранойей страдать.

Лично у меня задача была — найти удобное внешнее хранилище бэкапов, на случай «сервер умер и реанимации не подлежит», а не бункер для данных :)
avatar
Мы итак это всё публично в интернет выложили, собственно
Пароли юзеров тоже? А свой удалить из дампа надеюсь забыли? Пусть даже хеши. Они в лс насколько я помню не солёны и в мд5, который пора закопать, особенно без соли.
avatar
Они в лс насколько я помню не солёны и в мд5, который пора закопать, особенно без соли.
O! А вы пробовали взламывать хэши MD5 используя метод поиска коллизий или перебором по базе? У вас кластер под боком не самый слабый или очень много времени? То что это можно сделать, не значит что это просто сделать, и что кто-то будет заниматься такой фигнёй ради пароля человека на вашем сайте. :) Кроме того если вы вдруг не знали абсолютно стойкого алгоритма хеширования нету вообще даже нынешний «стандарт» SHA-512 не полностью надёжен, если так смотреть.

Так что не будем утрировать, то чем развлекаются математики не столь общедоступно, как кажется на первый взгляд, но MD5 устарел конечно.
avatar
То что это можно сделать, не значит что это просто сделать, и что кто-то будет заниматься
То, что на вашем сайте нет ничего интересного, (по сравнению например с сайтами гос. служб или платёжных систем) это ещё не значит, что вы защищены от таких вещей.
В полне может найтись какой нить студент или школьник, которому скучно и решил побаловаться.
Один факт кражи хоть и хешей будет достаточно не приятен.
avatar
Гос службам и платёжным системам я и не предлагаю бэкапится на Dropbox-e. Там за такую идею засмеют и буду правы :)

Какая задача, такое и решение, понятно же :)
avatar
Да, а что если к хранилищам дропбокса получат доступ третьи лица и сольют данные?

дампы нужно архивировать с длинным паролем перед заливкой на дропбокс, и проблема решена

Они в лс насколько я помню не солёны и в мд5, который пора закопать, особенно без соли.

Всё верно, не солятся и уязвимы для атак по таблицам. Поэтому не стоит хранить сырые данные на удаленном сервере
avatar
Убедили. Архив с базой буду паролем закрывать. :)
avatar
Уж лучше GnuPG. Надёжней.
avatar
При восстановлении кстати, если будет надо, будете проверять, действительно ли всё ок с бэкапом?
avatar
хорошо бы кто описал настройку бэкапов + амазон, дропбокс и пр. более основательно.
avatar
будет время — опишу популярно вариант с дропбоксом.
avatar
Там нечего описывать на само деле. Я делал по вот этой инструкции coredump.id.au/installing-dropbox-on-a-debian-server/ Мелкие неточности есть, но в целом инструкция вполне актуальна.
avatar
ну да

эта инструкция плюс скрипт типа этого

дамп на 200мб, если что
avatar
У меня архив сайта туда ходит в том числе. 900Mb
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.