Бэкап БД или файловой системы? Или все вместе? Если по отдельности — то снять дамп БД с текущего хостинга, создать новую БД с теми же параметрами на новом хостинге, залить дамп туда. Залить ФС и смотреть что получится.
Давно использую вот такой 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
так зачастую быстрее. У нас раньше в обязательном порядке было хранить три копии бэкапа данных: 1 на текущем хосте (в случае если надо быстро ресторнуть бд или файлы) второй на удаленном сервере, третий удаленный с удаленного сервера.
Глупо хранить бэкап там-же, где и сам ресурс. Даже, я сомневаюсь назвать это бэкапом. По большей части пустая трата ресурсов, ну и может быть «защита» от случайного rm.
тут либо бакула, либо дампить на локальную машину, затем рсинкать на удаленные.
xtrabackup или mysqldump сразу на удаленную машину — это плохо. особенно, когда базы вырастают до 5-10 гигов
# архивируем все каталоги, кроме тех, в которых находится файл .noarchive
# /bin/tar -zcf PATH-TO-DIR-BACKUP/$DATE.backup.tar.gz --exclude-tag=.noarchive ./
Прописал путь до папки лс, но почему то не бэкапит.
У меня bash скрипт по крону вызывает mysqldump, жмет результат в tar.gz и посылает по почте на ящик google.com. Ну и контроль, чтоб локально лежали бэкапы только за неделю — остальное удаляется.
Всё это долго описывать, а на деле скрипт-файл даже до 10 строк не дотягивает. Пока база не очень большая в сжатом виде — этого хватит :) А там посмотрим.
Я хочу выразить две благодарности господину rsmike
Во-первых за совет про --single-transaction ( чтобы там не говорил господин ewden mysqldump является простым и надёжным решением для бэкапа БД, пока она не доросла до гигабайтных размеров — а до этого ещё дожить надо.
Во-вторых за прекрасную идею про Dropbox. Халявное облачное пространство, которое без больших усилий мы раздули до 4Gb и бэкапы которые автоматом синхронизируются туда, а затем оттуда на домашний десктоп — это просто шикарно.
Gmugra , Насколько у вас большая база? Сколько времени занимает процесс бэкапа/восстановления? А обращали внимание на затраченные ресурсы во время копирования?
Вообще да, бэкапить в дропбокс, яндекс.диск паранойя не позволяет. Можно конечно взять и зашифровать архив с бэкапом используя например тот-же GnuPG. Но тут опять-же, до поры до времени.
Ну и вообще ладно. Дело ваше, надеюсь со временем поймёте, что есть более классные и лёгкие инструменты по сравнению с mysqldump.
Не помню сколько в виде дата файлов база занимает точно, врать не буду, но больше 100Mb. SQL-Dump — ~40Mb. Создаётся mysqldump-ом за секунд 5. Работает дамп ежедненво глубокой ночью, когда на сайте всё равно никого нет, так что даже если это и локает какие то таблицы — никого не задевает. Чтобы эти пройессы хоть ккто загружали наш сервер я вообще увидеть не смог. Да и нечему там загружать. Даже теоритически. А ваши опасеня начет облачного хранилища мне совсем не понятны. Во-первых можно и шифровать, да. Во-вторых эти бэкапа синхронизиуреуются у нас оттуда на домашние компы очень даже быстро (от размера файла зафисит). Решенье классное -
Опасения — сервера чужого дяди. Кто знает, что чужому дяде в голову придёт. Без шифрования ну уж точно не доверил бы. С шифрованием, наверно, тоже, подумал хорошо бы, перед тем как делать.
Насчёт слить на дом. тачку, в принципе решений и других может быть не мало.
А гуглу вы тоже не доверяете? Всю почту зашифрованой шлёте? А хостеру своему? :) Dropbox это же не Вася Пупеин & co. Dropbox — огромный сервис, нужны там ваши бэкапы кому-то. Кроме того в области защиты данных они там тоже на самотёк не пускают www.dropbox.com/privacy#security
Не доверяю. Не юзаю их ГуглХром даже, а юзаю Хромиум. А почта, с ней уже работаем давно только через tls/ssl. А хостер, я практически сам себе хостер, и имею круглосуточный физический доступ ко всем своим серверам и т.п. И не надо мне приводить ссылку на их политику приватности. Написать в ней можно всё что угодно. Огромным, простите, он как раз стал и из-за кучи доверчивых халявщиков.
Да, а что если к хранилищам дропбокса получат доступ третьи лица и сольют данные? Благо дело, в некоторых конторах шефы предусматривают это и запрещают на раз сотрудникам передавать служебные документы и т.п через подобные хранилища.
Вопрос во-первых в данных, конечно. В бэкапах нашего сайта, например, ничего особенно ценного для третьих лиц нет. Мы итак это всё публично в интернет выложили, собственно :)
Во-вторых вопрос доверия. Косяки бывают у всех. И у Dropbox того же был в 2010 году прецедент. Но это не повод уж совсем паранойей страдать.
Лично у меня задача была — найти удобное внешнее хранилище бэкапов, на случай «сервер умер и реанимации не подлежит», а не бункер для данных :)
Мы итак это всё публично в интернет выложили, собственно
Пароли юзеров тоже? А свой удалить из дампа надеюсь забыли? Пусть даже хеши. Они в лс насколько я помню не солёны и в мд5, который пора закопать, особенно без соли.
Они в лс насколько я помню не солёны и в мд5, который пора закопать, особенно без соли.
O! А вы пробовали взламывать хэши MD5 используя метод поиска коллизий или перебором по базе? У вас кластер под боком не самый слабый или очень много времени? То что это можно сделать, не значит что это просто сделать, и что кто-то будет заниматься такой фигнёй ради пароля человека на вашем сайте. :) Кроме того если вы вдруг не знали абсолютно стойкого алгоритма хеширования нету вообще даже нынешний «стандарт» SHA-512 не полностью надёжен, если так смотреть.
Так что не будем утрировать, то чем развлекаются математики не столь общедоступно, как кажется на первый взгляд, но MD5 устарел конечно.
То что это можно сделать, не значит что это просто сделать, и что кто-то будет заниматься
То, что на вашем сайте нет ничего интересного, (по сравнению например с сайтами гос. служб или платёжных систем) это ещё не значит, что вы защищены от таких вещей.
В полне может найтись какой нить студент или школьник, которому скучно и решил побаловаться.
Один факт кражи хоть и хешей будет достаточно не приятен.
46 комментариев
Для бэкапа файлов можно раскомментировать соответствующую строчку.
Также пути к некоторым командам типа find могут отличаться в разных системах.
xtrabackup или mysqldump сразу на удаленную машину — это плохо. особенно, когда базы вырастают до 5-10 гигов
Пользуясь случаем наверно зарекомендую к прочтению mega.co.nz/#!m0QVSRzR!EpK3qDTEOlZhOJF0MQTF-xobeLQUClHcMS0mpyws4X0
www.dropbox.com/install?os=lnx
Дропбокс для дебиана. Заводим аккаунт, получаем бесплатные 2Гб, монтируем, по желанию расшариваем бэкап-аккаунт с основным своим аккаунтом.
А вообще, по человечески, так бакулу юзаем.
вы просто не умеете его готовить
dev.mysql.com/doc/refman/5.1/en/mysqldump.html#option_mysqldump_single-transaction
вкратце: с ключом --single-transaction InnoDBшные таблицы не лочатся
В примере приведенном в топике, чтобы без этой блокировки было нужно так изменить?
Прописал путь до папки лс, но почему то не бэкапит.
Всё это долго описывать, а на деле скрипт-файл даже до 10 строк не дотягивает. Пока база не очень большая в сжатом виде — этого хватит :) А там посмотрим.
+ для быстрых операций, дополнительные локальные дампы таблиц, через automysqlbackup.
Во-первых за совет про --single-transaction ( чтобы там не говорил господин ewden mysqldump является простым и надёжным решением для бэкапа БД, пока она не доросла до гигабайтных размеров — а до этого ещё дожить надо.
Во-вторых за прекрасную идею про Dropbox. Халявное облачное пространство, которое без больших усилий мы раздули до 4Gb и бэкапы которые автоматом синхронизируются туда, а затем оттуда на домашний десктоп — это просто шикарно.
Спасибо!
Вообще да, бэкапить в дропбокс, яндекс.диск паранойя не позволяет. Можно конечно взять и зашифровать архив с бэкапом используя например тот-же GnuPG. Но тут опять-же, до поры до времени.
Ну и вообще ладно. Дело ваше, надеюсь со временем поймёте, что есть более классные и лёгкие инструменты по сравнению с mysqldump.
Насчёт слить на дом. тачку, в принципе решений и других может быть не мало.
Во-вторых вопрос доверия. Косяки бывают у всех. И у Dropbox того же был в 2010 году прецедент. Но это не повод уж совсем паранойей страдать.
Лично у меня задача была — найти удобное внешнее хранилище бэкапов, на случай «сервер умер и реанимации не подлежит», а не бункер для данных :)
Так что не будем утрировать, то чем развлекаются математики не столь общедоступно, как кажется на первый взгляд, но MD5 устарел конечно.
В полне может найтись какой нить студент или школьник, которому скучно и решил побаловаться.
Один факт кражи хоть и хешей будет достаточно не приятен.
Какая задача, такое и решение, понятно же :)
дампы нужно архивировать с длинным паролем перед заливкой на дропбокс, и проблема решена
Всё верно, не солятся и уязвимы для атак по таблицам. Поэтому не стоит хранить сырые данные на удаленном сервере
эта инструкция плюс скрипт типа этого
дамп на 200мб, если что