На жаль будь-хостер - це не вічно живий дідусь Ленін і потенційно володіє нехорошою тенденцією вмирати саме тоді, коли це найменше чекаєш. Ця трагічна випадковість і сталася минулого вівторка з моїм, тепер уже майже колишнім, хостером « Україна-Хост ».
Зрозуміло, що відразу ж метушитися я не став - потенційно, міг статися лише невеликий збій в роботі серверів і через максимум добу сайт б знову заробив (неприємно, але пережити можна). Але з огляду на, що сервер «впав» у вівторок вранці і станом на ранок четверга все так же валявся пузом догори і навіть не намагався встати, я зрозумів, що тут щастя мені точно не буде - і прийняв рішення переїжджати. (До речі, сервер піднявся тільки ввечері в неділю - через 6 днів з моменту падіння).
Найчастіше, головною бідою стає не тільки сама непрацездатність сайту, але і відсутність можливості швидко отримати резервні копії файлів і відразу ж перенести проекти до іншої, більш «живучою» хостинг-компанії. З огляду на, що в моєму випадку підтримка наполегливо ігнорувала всі питання на тему - «коли все запрацює» (що, в принципі, і зрозуміло - нічого відповідати), зв'язуватися з ними ще й з питання отримання резервних копій сенсу явно не було ні найменшого.
Відповідно, сьогодні ми поговоримо про те - як створити повноцінну резервну копію свого блогу чи сайту в автоматичному режимі і про ті кроки, які потрібно зробити в тому випадку, якщо ви розумієте, що необхідність в перенесенні проекту вже дійсно назріла.
Задовго до події, я створив акаунт на Dropbox (зареєструвавшись за цим посиланням, ви отримаєте +250 Мбайт дополнітельногго простору) - мене давно цікавила ідея організувати собі онлайн-сховище резервних копій сайтів, але з обов'язковою синхронізацією з локальним комп'ютером. З одного боку, зручність онлайну - всі копії завжди під руко й і в разі аварії легко відновлюються в будь-який момент і з будь-якого комп'ютера, а з іншого - переваги оффлайна, що дозволяють не залежати від працездатності сервісу.
Однак ручне бекапірованіе - процес дуже важкий і виснажливий, причому навіть не стільки фізично, скільки вимагає постійної «зарубки» в пам'яті - «не забути зробити бекап». Але ж всі ми пам'ятаємо, що WordPress славний не тільки великий ненажерливістю з точки зору пам'яті, але також і величезною кількістю різного роду плагінів, частина з яких виявляється дуже і дуже корисною.
Готуємося до «клінічної смерті»
Саме до цієї категорії плагінів і відноситься розширення під назвою WP Time Machine , Що дозволяє автоматично створювати резервні копії життєво важливих частин сайту із завантаженням отриманого архіву на Dropbox. Особливо потрібно відзначити той набір файлів, які входять до складу резервного пакета:
- повна копія бази MySQ L;
- повна копія вмісту папки wp-content;
- Основний файл .htaccess - лежить в корені сайту.
Одним з великих переваг формування саме такого пакета, є наявність в архіві всій папки «wp-content». На жаль, основна частина плагінів для бекапірованія найчастіше формує тільки копію бази даних, а ось файли потрібно зберігати вручну.
При цьому, директорія «wp-content», як ви пам'ятаєте, містить не тільки папку «uploads» з усіма завантаженими файлами, але також і папку з плагінами, темами і мовними файлами WordPress. Тобто, по-суті, це саме ті файли, які і є вашою особистою частиною блогу - все інше відноситься вже до платформи і розгортається на сервері за замовчуванням - при установці CMS. Єдине чого не вистачає, але, думаю, автор плагіна через деякий час додасть - це копії файлу wp-config.php.
Наявність папок «plugins», «themes» і «languages» дозволяє розгорнути сайт на новому місці проживання в кілька разів швидше, в порівнянні зі звичайною установкою WordPress. З одного боку - не потрібно вручну встановлювати все розширення, а з іншого - будь-які правки, внесені в файли плагінів - PHP, CSS, переклади плагінів, мовні змінні і т.д. - не треба оплачувати заново.
Давайте детально розглянемо настройки плагіна WP Time Machine, які я використовую. Відразу зверніть увагу, що у плагіна дещо нетрадиційний інтерфейс - вибір проводиться в одному і тому ж пункті опції.
Current offsite service: Dropbox - вибір сервісу для збереження резервних копій. Плагін надає 3 варіанти збереження ваших резервних копій: Dropbox, Amazon S3, FTP. Перший - зберігання резервних копій на серверах Dropbox , Другий - Amazon Simple Storage Service (Amazon S3) і третій - ваш зовнішній ftp-сервер.
Щодо зберігання резервних копій на ftp-сервері - Не настроюйте розташування сховища на той же сервер, де розташований сам сайт. Як показав досвід - сервера можуть не тільки позбавлятися подачі електроенергії або посипалися вінчестерів, але також і непогано горіти , А пожежні на додачу ще й заливають їх водою.
File format: .tar.gz - вибір формату для створення архіву. Альтернативою є формування архівів в zip, але на моєму сервері цей режим не заробив, а крім того - архів в .tar.gz менше за розміром, ніж в .zip.
Using Post Publish event to trigger backups - якщо включити цю опцію, то резервна копія буде створюватися автоматично при публікації нового запису в блозі.
Use time-stamped subdirectories to store multiple backups - формувати назву папки резервної копії із зазначенням дати і часу створення. Наприклад, «backup-2010-10-01».
Include cache related directories - включити в архів папку cache, розташовану в папці wp-content. В принципі, включати цю опцію немає особливої необхідності, хіба що вам з якоїсь причини необхідно обов'язково перенести кеш сторінок.
Stop logging | View log | Clear log - опції, що керують лог-файлами плагіна. Будь-які окремі настройки - не потрібні.
Email - якщо ви вибрали в якості сервісу для зберігання резервних копій Dropbox, в це поле необхідно ввести той email, з яким ви зареєстровані в сервісі.
Password - ваш пароль для доступу до сервісу Dropbox.
Після введення пароля, обов'язково натисніть на рядок «Save my Password» (вона зміниться на Do not save my Password "). В іншому випадку, пароль не збережеться і автоматичне створення резервних копій буде неможливо, тому що плагін не зможе увійти на сервер Dropbox.
Directory - папка в акаунті Dropbox, в яку будуть складатися сформовані резервні копії. Я використовую ось такий варіант «backups / proofsite / proofsite», в якому backups - основна папка для резервних копій, «proofsite» - папка для зберігання резервних копій цього блогу і «proofsite» - заготівля, до якої будуть приставлені час і дата створення архіву .
Після завершення налаштування, натискаємо кнопку «Generate wp Time Machine Archive», чекаємо появи напису про те, що архів створений і обов'язково перевіряємо його фізичне наявність на Dropbox.
Відроджуймось з попелу
Отже, до падіння сервера на «Україна-Хост», я встановив плагін WP Time Machine і, не дивлячись на те, що сервер був повністю недоступний - легко розгорнув копію блогу на новому сервері. Нижче описана послідовність моїх дій:
- Замовити та оплатити новий хостинг. До речі, багато хостинг-компанії надають 3-5 днів тестового періоду, яким можна скористатися як тимчасовим притулком - без оплати.
- Завантажити свіжу версію WordPress - раніше я користувався відмінною збіркою від Lecactus , Але останнім часом Іван перекваліфікувався в «ФотоКактус» і починаючи з 2.8.6, збірки перестали виходити. Відповідно, я взяв російську версію з офіційного сайту WordPress .
- Встановити свіжу версію на новий хостинг. Звичайна класична установка WordPress - нічого екстраординарного.
- Відкрити панель керування доменами реєстратора сайту і змінити DNS записи, перенаправивши адресацію домену на новий хостинг - зробимо це заздалегідь, щоб не втрачати час.
- Розпакувати архів «wpTimeMachine-content-files.tar.gz», раніше створений WP Time Machine.
- Закачати отримане вміст папки «wp-content» - на новий сервер за допомогою FTP або менеджера файлів, з заміною існуючих файлів.
- Перейменувати файл «wpTimeMachine-htaccess.txt» в «.htaccess» і закачати його в корінь нової копії WordPress.
- Створити за допомогою панелі управління хостингом нову базу даних, нового користувача і дати йому відповідні права.
- Відредагувати файл «wp-config-sample.php», додавши в нього інформацію про нову базу і новому користувача і перейменувавши його в «wp-config.php».
- Імпортувати вміст файлу «wpTimeMachine-data-files.sql» за допомогою phpMyAdmin в нову базу (функція «імпорт»). Створені WordPress на етапі установки демонстраційні дані будуть видалені.
- Дочекатися поновлення DNS (до 72 годин, але зазвичай набагато швидше) і відкрити сайт за старим домену, але на новому хостингу.
Ось так, за 11 простих кроків, я абсолютно без головного болю і хворобливих рухів тіла для отримання у попереднього хостера резервних копій, розгорнув нову версію блогу на іншому сервері, де ви в даний момент і читаєте цю статтю.
А як ви вирішували проблеми, у яких впав серверами і перенесенням сайту?
Зверніть увагу! wp Time Machine версії 1.9.21 викликає проблеми з завантажувачем зображень в WordPress 3.3! Або відкотіться на версію 1.9.16 (у мене вона працює) або до появи нової версії, рекомендується не використовувати цей плагін.
А як ви вирішували проблеми, у яких впав серверами і перенесенням сайту?
