IHHI-Blog

Печальную историю МК помните? Не хотите, чтобы это повторилось с вами? Предохраняйтесь. Сохраняйтесь. Что делать с файлами, знают все - их нужно просто периодически копировать в надёжное место. Но современные сайты в 9 случаях из 10 используют базу данных. Остальной 1 случай готовится её использовать. И вот с этим элементом всё немного сложнее. Разберёмся с MySQL - а именно эта система управления базами данных (СУБД/DBMS) используется на простых сайтах, блогах и т.п.

Практически каждый, кто слышал про MySQL, слышал и про phpMyAdmin - веб-приложение, которое позволяет произвести ряд манипуляций с базой данных и, при необходимости, сделать копию самой базы. Овладев этими знаниями, владельцы сайтов успокаиваются: не ищут иных знаний и не делают резервных копий. Признаюсь честно: я тоже не делаю. Есть люди, которые могут ежедневно запускать браузер, заходить в нужные места и делать правильные действия. Я не из их числа. Для однообразных и повторяющихся действий нужно использовать компьютеры и соответствующее ПО. И второй минус phpMyAdmin - ограничение на размер импортируемой базы данных. Конкретная цифра зависит от настроек провайдера. Вот данные по провайдерам по состоянию на дату выхода статьи (часть ссылок - реферальные):

• .masterhost - 32mb
  
• ТаймВэб - 40mb
  
• BeGet.ru - 999mb
  
• Домишко - 50mb
  
• LavaHost - 32mb
  

Много это или мало? Для примера: размер базы данных этого блога, созданных сборок ("Край земли", "Валентинка", IHHI-X) и данных IHHIndex составляет (!) 140 мегабайт. Наверное 80% занимают логи, но почему я должен отказываться от них? Там огромное количество IP спамеров, поисковых и других роботов, которыми я собираюсь воспользоваться. Т.е. только один провайдер позволит сделать backup и последующее восстановление из него без дополнительных шагов. И если припрёт, я соображу, как перепрыгнуть пропасть тройным прыжком, но ведь должны быть способы лучше.

А теперь представьте себе увлекательный процесс перегонки веб-странички размером в 140 мегабайт от провайдера к себе и обратный процесс? Если эта перспектива не вызвала внутреннего отторжения, то составьте расписание создания резервных копий и неуклонно следуйте ему. Всех, кого перспектива ручного резервного копирования блога (а может блогов?) не радует, жду здесь завтра - проведу мастер-класс по облегчению собственной участи.

Но данные сохраните прямо сейчас . Любым способом. И самое главное - проверьте, можно ли из полученной копии восстановиться. История знает массу случаев, когда многолетнее резервное копирование на поверку оказывалось пшиком и накопленные данные были непригодны для восстановления.

Теги этой статьи: backup, dbms, mysql, phpmyadmin, резервное копирование, субд