В даному документідокладно розглядаються принципи та процедури, яких необхідно дотримуватись для реалізації стратегії резервного копіювання MySQL на рівні підприємства при використанні агента для MySQL.
Даний посібник користувача містить опис різних методів та стратегій, щоб проводити резервне копіювання баз MySQL та їх відновлення за допомогою агента версії Enterprise. Ці методи також дозволяють адаптувати та налаштовувати ПЗ з метою покращення продуктивності, ефективності, швидкості та масштабованості різних підходів до резервного копіювання баз MySQL та відповідних даних.
Автоматичне резервне копіювання MySQL розроблено з метою спростити та прискорити процедуру резервного копіювання баз MySQL та відновлення MySQL. Програмне забезпеченнядля бекапу бази даних MySQL та її відновлення створено таким чином, що адміністратору не потрібно знати, як працюють вбудовані інструменти резервного копіювання MySQL, ні вміти створювати складні скрипти. Автоматичний бекап MySQL за допомогою Bacula автоматично створить резервну копію важливої інформації, наприклад, конфігурації або визначення користувача. Бекап бази даних MySQL також підтримує два методи: резервне копіювання за допомогою дампа та бінарних логів.
Резервне копіювання MySQL доступний для платформ Linux 32 і 64 біти (платформи Debian, Ubuntu, CentOS та ін.), і підтримує MySQL 4.0.x, 4.1.x, 5.0.x, 5.5.x, 5.6.x.
Як зробити бекап MySQL: дамп чи бінарний лог?
Таблиця, наведена нижче, допоможе вам вибрати один із методів резервного копіювання баз MySQL. Щоб вибрати, як зробити бекап бази даних MySQL, необхідно вирішити, чи хочете ви мати можливість відновлювати MySQL до певної контрольної точки, або фільтрувати об'єкти під час створення резервної копії або відновлення MySQL. Також можна комбінувати обидва методи резервного копіювання MySQL для одного сервера.
| Можливості автоматичного бекапу MySQL | Дамп файл | Бінарний лог |
| Можливість відновлення одиничного об'єкта MySQL (таблиця, схема…) | Так | Ні |
| Швидкість резервного копіювання MySQL | Повільно | Швидко |
| Швидкість відновлення MySQL | Дуже повільно | Швидко |
| Розмір бекапу бази MySQL | Маленький | Великий |
| Можливість відновлення MySQL до контрольної точки | Так | Так |
| Підтримка інкрементального/диференціального бекапу MySQL | Так | Так |
| Онлайн бекап MySQL | Так | Так |
| Узгодженість | Так | Так |
| Відновлення MySQL до попередньої основної версії | Так | Ні |
| Можливість відновити MySQL до нової основної версії | Так | Ні |
Оцінка інформації при бекапі таблиці MySQL
Команда estimateдає змогу відобразити всю інформацію, знайдену агентом MySQL. У разі режиму дампа, наше програмне забезпечення не може оцінити розмір дамп файлу для БД. Натомість воно відобразить розмір БД.
Інформація про резервне копіювання MySQL у режимі дампа
Агент MySQL згенерує такі файли в каталозі Bacula для сервера, що має єдину базу даних “test”.
| Файл | Тип | Пояснення |
| global-grants.sql | глобальний | Список користувачів, їх паролі та спеціальні функції |
| settings.txt | глобальний | Поточні змінні для mysql сервера |
| my.cnf | глобальний | Конфігурація MySQL |
| createdb.sql | БД | Скрипт створення БД |
| schema.sql | БД | Скрипт створення схеми БД |
| data.sql | БД | Дані БД у форматі дампа |
| grants.sql | БД | Список усіх користувачів, пов'язаних із БД |
Таблиця 2. Зміст бекапу MySQL як дампа
Відновлення MySQL
Bacula дозволяє відновити бекап MySQL у кількох режимах відновлення:
- Відновлення MySQL із дамп файлу або бінарних логів
- Відновлення користувачів та ролей
- Відновлення єдиної бази даних MySQL
- Відновлення MySQL до контрольної точки
Щоб відновити бекап MySQL у режимі бінарних логів, агент використовує утиліту percona.
Рисунок 3: Вміст сервера під час відновлення MySQL
Рисунок 4: Вміст БД під час відновлення MySQL
Як зробити бекап бази даних MySQL без використання плагіна безкоштовно
Створення дампи бази даних MySQL
Цей спосіб повністю безкоштовний, оскільки дозволяє робити бекап MySQL за допомогою open source версії Bacula Community і без додаткових плагінів. Для резервного копіювання невеликих баз даних MySQL можна використовувати прості bash-скрипти. Для випадку з резервним копіюванням баз MySQL можна зробити скрипт бекапу MySQL, який запускатиметься на клієнті і робитиме dump бази даних MySQL.
mysqldump -uuser -ppassword -all-databases | gzip > /opt/mysql_backup/backup.`date +%F`.sql.gz
find /home/bacula-backup/ -type f -mtime +3 -exec rm -f()\;
Цей скрипт бекапу MySQL збереже дамп всіх БД MySQL в директорію /opt/mysql_backup/ з якої ми будемо робити резервні копії дамп бази даних, за допомогою директиви .
Приклад завдання на бекап бази MySQL:
Name = "BackupSmallMysqlServer"
Level = Incremental
Client = mysqlserver1
FileSet = "mysqlserver"
Schedule = "WeeklyCycle"
Messages = Standard
ClientRunBeforeJob = "/opt/sbin/mysql.sh"
SpoolAttributes = yes
Write Bootstrap = "/var/lib/bacula/%c.bsr"
Name = "mysqlserver"
compression = GZIP
File = /opt/mysql_backup/
Цей спосіб застосовується для бекапу ненавантажених баз даних MySQL, наприклад, баз даних невеликих сайтів, для яких блокування таблиць під час дампа не критична
Як зробити бекап навантажених баз даних MySQL?
Якщо база даних MySQL сильно навантажена, то рекомендується у ньому робити дамп, оскільки таблиці тимчасово дампа блокуються. Найправильніше рішення в цьому випадку – зробити репліку бази даних Master-Slave Replication.
Для навантажених систем репліка потрібно, щоб у разі поломки бази даний Master, можна було переключити навантаження на Slaveі зробити його новим Master.
Для навантажених систем резервне копіювання MySQL необхідно робити саме для Slaveбази даних.
Сервери баз даних - одні з ключових у будь-якій організації. Саме вони зберігають інформацію та надають видачу на запит, і вкрай важливо зберегти БД у будь-якій ситуації. Базове постачання зазвичай включає потрібні утиліти, але адміну, який не стикався до цього з БД, доведеться деякий час розбиратися з особливостями роботи, щоб забезпечити автоматизацію.
Види бекапів баз даних
Спочатку розберемося з тим, які взагалі бувають бекапи. Сервер баз даних не є звичайним десктопним додатком, і щоб забезпечити виконання всіх властивостей ACID (Atomic, Consistency, Isolated, Durable), використовується ряд технологій, а тому створення і відновлення БД з архіву має свої особливості. Існують три різні підходи до резервного копіювання даних, кожен з яких має свої плюси та мінуси.
При логічному, або SQL, бекапі (pg_dump, mysqldump, SQLCMD) створюється миттєвий знімок вмісту бази з урахуванням транзакційної цілісності та зберігається у вигляді файлу з SQL-командами (можна вибрати всю базу або окремі таблиці), за допомогою якого можна відтворити базу даних на іншому сервері. На це потрібен час (особливо для великих баз) для збереження та відновлення, тому часто цю операцію виконувати не можна і її проводять під час мінімального навантаження (наприклад, вночі). При відновленні адміністратору необхідно буде виконати кілька команд, щоб підготувати все необхідне (створити порожню базу даних, облікові записита інше).
Фізичний бекап (рівня файлової системи) – копіювання файлів, які СУБД використовує для зберігання даних у базі даних. Але при простому копіюванні ігноруються блокування та транзакції, які, швидше за все, будуть неправильно збережені та порушені. При спробі приєднати цей файл він буде у неузгодженому стані та призведе до помилок. Щоб отримати актуальний бекап, базу даних потрібно зупинити (можна зменшити час простою, використавши два рази rsync – спочатку на працюючій, потім на зупиненій). Нестача цього методу очевидна - не можна відновити певні дані, лише всю базу даних. При старті БД, відновленої з архіву файлової системи, необхідно провести перевірку на цілісність. Тут застосовуються різні допоміжні технології. Наприклад, у PostgreSQL логи попереджувальної журналізації WAL (Write Ahead Logs) та спеціальна функція (Point in Time Recovery – PITR), що дозволяє повернутися до певного стану бази. За допомогою їх легко реалізується третій сценарій, коли бекап рівня файлової системи об'єднується з резервною копією WAL-файлів. Спочатку відновлюємо файли резервної копії файлової системи, а потім за допомогою WAL база наводиться актуальним станом. Це трохи складніший підхід для адміністрування, зате немає проблем із цілісністю БД та відновленням баз до певного часу.
Логічний бекап використовується в тих випадках, коли необхідно одноразово зробити повну копію бази або у повсякденній експлуатації для створення копії не потрібно багато часу або місця. Коли ж вивантаження баз займає багато часу, слід звернути увагу до фізичне архівування.
Barman
Ліцензія: GNU GPL
Підтримувані СУБД: PostgreSQL
PostgreSQL підтримує можливості фізичного та логічного бекапу, додаючи до них ще один рівень WAL (див. урізання), який можна назвати безперервним копіюванням. Але керувати за допомогою штатних інструментівДекількома серверами не дуже зручно навіть адміну зі стажем, а у разі збою рахунок йде на секунди.
Barman (backup and recovery manager) – внутрішня розробка компанії 2ndQuadrant, що надає послуги на базі PostgreSQL. Призначений для фізичного бекапу PostgreSQL (логічний не підтримує), архівування WAL та швидкого відновлення після збоїв. Підтримуються віддалений бекап та відновлення кількох серверів, функції point-in-time-recovery (PITR), керування WAL. Для копіювання та подачі команд на віддалений вузол використовується SSH, синхронізація та бекап за допомогою rsync дозволяє скоротити трафік. Також Barman інтегрується зі стандартними утилітами bzip2, gzip, tar та подібними. В принципі, можна використовувати будь-яку програму стиснення та архівування, інтеграція не триватиме багато часу. Реалізовано різні сервісні та діагностичні функції, що дозволяють контролювати стан сервісів та регулювати смугу пропускання. Підтримуються Pre/Post-скрипти.
Barman написаний на Python, управління політиками резервного копіювання провадиться за допомогою зрозумілого INI-файлу barman.conf, який може перебувати в /etc або домашньому каталозі користувача. У поставці йде готовий шаблон із докладними коментарями всередині. Працює лише на *nix-системах. Для встановлення в RHEL, CentOS та Scientific Linux слід підключити EPEL - репозиторій, в якому містяться додаткові пакети. У розпорядженні користувачів Debian/Ubuntu офіційний репозиторій:
$ sudo apt-get install barman
У репозиторії не завжди остання версія, для її встановлення доведеться звернутися до вихідних текстів. Залежностей небагато, і розібратися у процесі нескладно.
Sypex Dumper
Ліцензія: BSD
Підтримувані СУБД: MySQL
Разом з MySQL поставляються утиліти mysqldump, mysqlhotcopy, що дозволяють легко створити дамп бази даних, вони добре документовані, і в інтернеті можна знайти велику кількість готових прикладів та фронтендів. Останні дозволяють новачкові швидко розпочати роботу. Sypex Dumper є PHP-скриптом, що дозволяє легко створити і відновити копію бази даних MySQL. Створювався для роботи з великими базами даних, працює дуже швидко, зрозумілий та зручний у використанні. Вміє працювати з об'єктами MySQL – уявленнями, процедурами, функціями, тригерами та подіями.
Ще один плюс, на відміну від інших інструментів, при експорті виробляючих перекодування в UTF-8, - в Dumper експорт виробляється в рідному кодуванні. Результуючий файл займає менше місця, а процес відбувається швидше. В одному дампі можуть бути об'єкти з різними кодуваннями. Причому легко імпорт/експорт зробити кілька етапів, зупиняючи процес під час навантаження. При поновленні процедура розпочнеться з місця зупинки. Під час відновлення підтримується чотири варіанти:
- CREATE + INSERT – стандартний режим відновлення;
- TRUNCATE + INSERT - менше часу створення таблиць;
- REPLACE – відновлюємо в робочій базі старі дані, не затираючи нові;
- INSERT IGNORE - додаємо в базу видалені або нові дані, не чіпаючи наявні.
Підтримується стиснення копії (gzip або bzip2), видалення старих бекапів, реалізований перегляд вмісту дамп-файлу, відновлення тільки структури таблиць. Є й сервісні функції управління БД (створення, видалення, перевірка, відновлення БД, оптимізація, очищення таблиць, робота з індексами та інше), і навіть файл-менеджер, що дозволяє копіювати файли на сервер.
Управління здійснюється за допомогою веб-браузера, інтерфейс з використанням AJAX локалізований з коробки і створює враження роботи з настільною програмою. Також можна запускати завдання з консолі та за розкладом (через cron).
Для роботи Dumper знадобиться класичний L|WAMP-сервер, установка звичайна для всіх програм, написаних на PHP (копіюємо файли та встановлюємо права), і не буде складною навіть для новачка. Проект надає детальну документацію та відеоуроки, що демонструють роботу з Sypex Dumper.
Є дві редакції: Sypex Dumper (безкоштовно) та Pro (10 доларів). Друга має більше можливостей, всі відмінності наведено на сайті.
SQL Backup And FTP
Ліцензія:
Підтримувані СУБД: MS SQL Server
MS SQL Server - одне з популярних рішень, тому зустрічається досить часто. Завдання резервного копіювання створюється за допомогою середовища SQL Server Management Studio, власне Transact-SQL та командлетів модуля SQL PowerShell (Backup-SqlDatabase). На сайті MS можна знайти величезну кількість документації, яка дозволяє розібратися з процесом. Документація хоч і повна, але дуже специфічна, а інформація в Інтернеті часто суперечить одна одній. Новачку дійсно спочатку потрібно потренуватися, «набивши руку», тому, навіть незважаючи на все сказане, стороннім розробникам є де розвернутися. До того ж безкоштовна версія SQL Server Expressне може похвалитися вбудованим інструментом для резервного копіювання. Для ранніх версій MS SQL (до 2008) можна знайти безкоштовні утиліти, наприклад SQL Server backup , але в більшості подібні проекти вже комерціалізувалися, хоча пропонують всю функціональність часто за символічну суму.
Наприклад, розробка SQL Backup And FTP та One-Click SQL Restore відповідає принципу «настроїв та забув». Володіючи дуже простим і зрозумілим інтерфейсом, вони дозволяють створювати копії баз даних MS SQL Server (включаючи Express) та Azure, зберігати зашифровані та стислі файлина FTP та хмарних сервісах(Dropbox, Box, Google Drive, MS SkyDrive або Amazon S3), результат можна побачити. Можливий запуск процесу як вручну, так і за розкладом, відправлення повідомлення про результат завдання по email, запуск скриптів.
Підтримуються всі варіанти бекапу: повний, диференціальний, журнал транзакцій, копіювання папки з файлами та багато іншого. Старі резервні копії автоматично видаляються. Для підключення до віртуального вузла використовується SQL Management Studio, хоча тут можуть бути нюанси і це буде працювати не у всіх конфігураціях. Для завантаження пропонується п'ять версій - від безкоштовної Freeдо навороченої Prof Lifetime (на момент написання цих рядків коштувала лише 149 доларів). Функціонала Free цілком достатньо для невеликих мереж, у яких встановлено один-два SQL-сервери, всі основні функції активні. Обмежено кількість резервних БД, можливість надсилання файлів на Google Drive та SkyDrive та шифрування файлів. Інтерфейс хоч і не локалізований, але дуже простий і зрозумілий навіть новачкові. Потрібно лише підключитися до SQL-серверу, після чого буде виведено список баз даних, слід зазначити потрібні, настроїти доступ до віддалених ресурсів та вказати час виконання завдання. І все це в одному вікні.
Але є одне але". Сама програма не призначена для відновлення архівів. Для цього пропонується окрема безкоштовна утиліта One-Click SQL Restore, яка розуміє і формат, створений командою BACKUP DATABASE. Адміну необхідно лише вказати архів та сервер, на який відновити дані, та натиснути одну кнопку. Але в складніших сценаріях доведеться використовувати RESTORE.
Особливості бекапу MS SQL Server
Створення резервної копії та відновлення СУБД має свої відмінності, які потрібно враховувати, особливо їх багато у разі перенесення архіву на інший сервер. Наприклад розберемо деякі нюанси MS SQL Server. Для архівування за допомогою Transact-SQL слід використовувати команду BACKUP DATABASE (є і різницева DIFFERENTIAL) та журнал транзакцій BACKUP LOG.
Якщо резервна копія розгортається на іншому сервері, потрібно переконатися, що присутні ті ж логічні диски. Як варіант - можна вручну прописати правильні шляхи для файлів бази даних, використовуючи опцію WITH MOVE команди RESTORE DATABASE.
Проста ситуація - бекап та перенесення баз на інші версії SQL Server. Ця операція підтримується, але в разі SQL Server буде працювати, якщо версія сервера, на якій розгортається копія, така ж чи новіша, ніж та, на якій вона створювалася. Причому є обмеження: новіші не більше ніж на дві версії. Після відновлення БД перебуватиме у режимі сумісності з тією версією, з якою здійснювався перехід, тобто нові функції будуть недоступні. Це легко виправити, змінивши COMPATIBILITY_LEVEL. Це можна зробити за допомогою GUI або SQL.
ALTER DATABASE MyDB SET COMPATIBILITY_LEVEL = 110;
Визначити, на якій версії було створено копію, можна, переглянувши заголовок файлу архіву. Щоб не експериментувати, при переході на нову версію SQL Server слід запустити безкоштовну утиліту Microsoft Upgrade Advisor.
Iperius
Ліцензія:комерційна, є версія
Підтримувані СУБД: Oracle 9–11, XE, MySQL, MariaDB, PostgreSQL та MS SQL Server
Коли доводиться керувати кількома типами СУБД, без комбайнів не обійтись. Вибір великий. Наприклад, Iperius - легка, дуже проста у використанні та одночасна потужна програмадля резервного копіювання файлів, що має функцію гарячого резервування бази даних без переривання в роботі або блокування. Забезпечує повний або інкрементальний бекап. Може створювати повні образи дисків для автоматичної переустановки системи. Підтримує резервне копіювання на NAS, USB-пристрої, стримери, FTP/FTPS, Google Drive, Dropbox і SkyDrive. Підтримує стиснення zip без обмеження у розмірі файлів та AES256-шифрування, запуск зовнішніх скриптів та програм. Включає функціональний планувальник завдань, можливо паралельне або послідовне виконання декількох завдань, результат відправляється на email. Підтримуються численні фільтри, змінні для персоналізації шляхів та налаштувань.
Можливість закачування FTP дозволяє легко оновлювати інформацію на декількох веб-сайтах. Відкриті файлирезервуються за допомогою технології VSS ( тіньового копіюваннятомів), що дозволяє виробляти гарячий бекап як файлів СУБД, а й інших додатків. Для Oracle також використовується засіб організації резервного копіювання та відновлення даних RMAN (Recovery Manager). Щоб не перевантажувати канал, можна налаштувати смугу пропускання. Управління резервуванням та відновленням здійснюється за допомогою локальної та веб-консолі. Всі функції на увазі, тому для налаштування завдання потрібно лише розуміння процесу, документацію заглядати навіть не доведеться. Просто слідуємо підказкам майстра. Також можна відзначити менеджер облікових записів, що дуже зручно за великої кількості систем.
Базові функції пропонуються безкоштовно, але можливість резервування БД закладено лише у версіях Advanced DB та Full. Підтримується установка від XP до Windows Server 2012.
Handy Backup
Ліцензія:комерційна
Підтримувані СУБД: Oracle, MySQL, IBM DB2 (7-9.5) та MS SQL Server
Одна з найпотужніших систем управління реляційними базами даних - IBM DB2, що має унікальні функції масштабування і підтримує безліч платформ. Поставляється у кількох редакціях, що побудовані на одній базі та відрізняються функціонально. Архітектура баз даних DB2 дозволяє керувати практично всіма типами даних: документами, XML, медіафайлами тощо. Особливо популярна безкоштовна DB2 Express-C. Бекап дуже простий:
DB2 backup db sample
Або снапшот, який використовує функцію Advanced Copy Services (ACS):
Db2 backup db sample use snapshot
Але слід пам'ятати, що у разі знімків ми не можемо відновлювати окремі таблиці (db2 recover db). Є і можливості з автоматичного бекапу, і багато іншого. Продукти добре документовані, хоча у російськомовному інтернеті керівництва зустрічаються рідко. Також далеко не у всіх спеціальних рішеннях можна знайти підтримку DB2.
Наприклад, Handy Backup дозволяє виконувати бекап декількох типів серверів баз даних та зберігати файли практично на будь-який носій ( жорсткий диск, CD/DVD, хмарне та мережеве сховище, FTP/S, WebDAV та інші). Можливий бекап баз даних через ODBC (тільки таблиці). Це одне з небагатьох рішень, що підтримують DB2, і має логотип «Ready for IBM DB2 Data Server Software». Вся процедура виконується за допомогою звичайного майстра, в якому необхідно вибрати потрібний пункт і сформувати завдання. Сам процес налаштування настільки простий, що може розібратися і новачок. Можна створити кілька завдань, які запускатимуться за розкладом. Результат фіксується в журналі та надсилається по email. Під час роботи завдання зупинення сервісу не потрібне. Архів автоматично стискається та шифрується, що гарантує його безпеку.
Роботу з DB2 підтримують дві версії Handy Backup – Office Expert (локальний) та Server Network (мережевий). Працює на комп'ютерах під керуванням Win8/7/Vista/XP або 2012/2008/2003. Сам процес розгортання нескладний будь-якого адміну.
Всім привіт! Бувають ситуації, коли після встановлення нового розширення або теми на сайт інтернет-магазину виникають різні непередбачувані ситуації. Вони полягають у тому, що на сайті можуть з'явитися помилки, яких раніше не було або сайт взагалі не відповідає. Щоб бути готовим до таких ситуацій, потрібно робити резервні копії сайту або бекап. В ідеалі їх потрібно створювати вручну щоразу, як встановлюєте на сайт новий модуль, або робите операції, які стосуються бази даних або файлів сайту. Я роблю бекапи щотижня про всяк випадок. Просто у мене завжди багато оновлень з'являється за тиждень.
Резервне копіювання файлів сайту вручну
Як правило, на хороших хостингах, Існує власна система резервного копіювання даних. Вона робить бекап вашого сайту з певним періодом, зазвичай це кілька днів. Зрозуміло, що повністю покладатись на хостинг у резервному копіюванні не варто. Як тоді зробити резервну копію? Ми будемо використовувати.
Насамперед потрібно створити резервну копію файлів. Для цього йдемо до розділу «WebFTP». Тут вибираємо сайт, файли якого ми хочемо зарезервувати, і переходимо до його папки. Потім, для швидшого завантаження, файли спочатку потрібно заархівувати. Архівувати файли можна зі стиском і без нього. Я б рекомендував не стискати файли, і додавати їх до архіву у звичайному вигляді, щоб не пошкодити надалі. Виділяємо потрібні нам каталоги і файли, у списку, що випадає, внизу, вибираємо дію «Запакувати в архів». Задаємо для нього ім'я, бажано із зазначенням дати та часу, коли було створено копію. Тиснемо кнопку «Виконати».
Чекаємо деякий час, щоби архів створився. Після цього викачуємо його на комп'ютер. Резервна копія файлів готова.
Резервне копіювання бази даних вручну
Тепер переходимо до не менш важливої дії – резервування бази даних. Якщо хостинг не дозволяє зробити це автоматично, то в таких випадках, щоб зберегти копії у себе на комп'ютері, потрібно робити експорт бази даних. Робиться це так. Переходимо до розділу «Бази даних» та клацаємо за посиланням «PHPMyAdmin» навпроти потрібної БД.
В відкритій вкладцівводимо свій логін та пароль, і ми потрапляємо до панелі управління базами даних MySQL. Натискаємо на назву бази даних (1), яку хочемо зарезервувати і переходимо у вкладку «Експорт» (2).
Вибираємо спосіб з мінімумом налаштувань і тиснемо "Вперед". Після цього почнеться завантаження sql-файлу з копією бази даних.
Відновлення бази даних із резервної копії
Для відновлення бази з цього файлу потрібно також увійти в панель керування базами MySQL, видалити всі наявні в базі таблиці і потім перейти у вкладку Імпорт. Там вибрати раніше створений файл і натиснути кнопку «Поїхали». Система його завантажить та повідомить про завершення операції. У базі даних буде створено всі таблиці, які вона містила на момент створення резервної копії.
Відновлення файлів із резервної копії
З відновленням файлів дещо простіше. Заходимо до розділу «WebFTP», далі в папку вашого сайту, видаляємо всі файли всередині папки вашого сайту та натискаємо «Завантажити файл». Вибираємо раніше створений архів і тиснемо "Завантажити файл". Чекаємо на закінчення завантаження.
Після того, як архів завантажився та відображається на панелі файлів, потрібно його розархівувати. І все готове. Або можна не видаляючи файли просто завантажити архів та розорхівувати із заміною. Якщо розархівація пройшла успішно, це означає, що всі файли замінені з резервної копії. Але я зазвичай спочатку видаляю файли, а потім розархівую резервну копію.
Також файли можна завантажити за допомогою FTP-клієнта, наприклад FileZilla. Про те, як з ним працювати, я писав. Підключаємось до свого ftp-акаунту через клієнт, заходимо в папку з файлами сайту і просто копіюємо їх на свій комп'ютер. Так само їх можна завантажити з комп'ютера на хостинг. Тільки не забуваємо копіювати із заміною.
Не забувайте про безпеку свого сайту, ставтеся серйозно до резервних копій, тому що ніколи не знаєш, коли вони можуть стати в нагоді.
З повагою, Шмідт Микола
Організовуємо автоматичні бекапи бази даних MySQL.
Кожна база даних має бути підстрахована резервним копіюванням або бекапом (backup). Якщо ви все ще робите це вручну, можете радіти, тому що є просте рішення автоматичного бекапу на PHP. За допомогою цього скрипта ви можете передавати конкретні таблиці для резервного копіювання або зробити резервне копіювання всієї бази даних.
Як продати mysql backups?
Найкраще скопіювати код наданого скрипта і помістити його в папку database_backups, як показано на скріншоті нижче. Потім під час виклику файлу backup.php, він буде створювати резервну копію бази даних на вашому сервері. Я б рекомендував періодично копіювати всі файли бекапів собі на комп'ютер або інше сховище, щоб перестрахуватися на випадок втрати хостингу.
Автоматизація mysql backups за допомогою CRON
CRON є перевіреним планувальником завдань, який дозволяє запускати скрипти в певний час. Наприклад, можна робити бекапи бази даних уночі, коли падає трафік. Ви можете легко налаштувати CRON, якщо його підтримує ваш хостинг. Для цього вам необхідно виконати наступну команду, в якій потрібно просто змінити посилання на ваш файл, що створює бекапи.
Wget -O /dev/null http://your-site.com/database_backup/backup.php
PHP код файлу
Ми розглянули простий приклад реалізації автоматичного бекапу бази даних mysql. Так, спосіб дубовий, але він є прийнятним для маленьких сайтів. Якщо у вас великий проект, то використання php дуже повільне порівняно з використанням mysqldump. Переконливе прохання до тих, хто знає, як організувати резервне копіювання краще, напишіть у коментарях.
1 лютого 2012 о 00:33Резервне копіювання даних у MySQL
- MySQL
Резервне копіювання бази даних - це така штука, яку завжди доводиться налаштовувати для вже працюючих проектів прямо на «живих» production-серверах.
Подібна ситуація легко зрозуміла. На початку будь-який проект ще порожній і там просто нічого копіювати. У фазі бурхливого розвитку голови нечисленних розробників зайняті виключно прикручуванням фішок та рюшок, а також фіксом критичних баг з дедлайном «позавчора». І тільки коли проект «злетить», приходить усвідомлення, що основна цінність системи - це накопичена база даних, і її збій стане катастрофою.
Ця оглядова стаття – для тих, чиї проекти вже досягли цієї точки, але смажений півень ще не клюнув.
1. Копіювання файлів бази
Базу даних MySQL можна скопіювати, якщо тимчасово вимкнути MySQL-сервер і просто скопіювати файли з папки /var/lib/mysql/db/. Якщо сервер не вимкнути, з очевидних причин можлива втрата та псування даних. Для великих навантажених баз ця можливість близька до 100%. Крім того, при першому запуску з «брудною» копією бази даних MySQL сервер почне процес перевірки всієї бази, який може затягнутися на годинник.У більшості «живих» проектів регулярне вимкненнясервера БД тривалий час неприйнятно. Для вирішення цієї проблеми застосовується трюк, що базується на снепшотах файлової системи. Снепшот - це щось подібне до «фотографії» файлової системи на певний момент часу, зроблений без реального копіювання даних (і тому швидко). Аналогічно працює «ледаче копіювання» об'єктів у багатьох сучасних мовах програмування.
Загальна схема дій така: блокуються всі таблиці, скидається файловий кеш БД, робиться снепшот файлової системи, розблоковуються таблиці. Після цього файли спокійно копіюються зі снепшота, після чого він знищується. "Блокуюча" частина такого процесу займає час порядку секунд, що вже терпимо. Як розрахунок на якийсь час, поки "живий" снепшот, знижується продуктивність файлових операцій, що в першу чергу б'є за швидкістю операцій запису в базу.
Деякі файлові системи, наприклад, ZFS, підтримують зняття снепшотів нативно. Якщо ви не користуєтеся ZFS, але на вашому сервері стоїть менеджер томів LVM, ви також зможете скопіювати базу MySQL через сніпшот. Нарешті, під *nix можна скористатися драйвером снепшотів R1Soft Hot Copy, але цей спосіб не запрацює в контейнері openvz().
Для баз MyISAM існує офіційна безкоштовна утиліта mysqlhotcopy, яка "правильно" копіює файли баз MyISAM без зупинки сервера. Існує аналогічна утиліта для InnoDB, але вона платна, хоч і можливостей у ній більше.
Копіювання файлів – самий швидкий спосібперекинути базу даних з одного сервера на інший.
2. Копіювання через текстові файли
Для того, щоб рахувати в бекапі дані з production-бази, необов'язково смикати файли. Можна вибрати дані запитом та зберегти їх у текстовий файл. Для цього використовується SQL команда SELECT INTO OUTFILE і парна їй LOAD DATA INFILE . Вивантаження проводиться рядково (можна відібрати для збереження лише потрібні рядки, як у звичайному SELECT). Структура таблиць ніде не вказується – про це має дбати програміст. Він також повинен подбати про включення команд SELECT INTO OUTFILE у транзакцію, якщо це необхідно для забезпечення цілісності даних. На практиці SELECT INTO OUTFILE використовується для часткового бекапу дуже великих таблиць, які не можна скопіювати жодним іншим чином.У більшості випадків набагато зручніша створена Ігорем Романенком утиліта mysqldump. Утиліта mysqldump формує файл, що містить всі SQL-команди, потрібні для повного відновлення БД на іншому сервері. Окремими опціями можна домогтися сумісності цього файлу практично з будь-якою СУБД (не тільки MySQL), крім того, існує можливість вивантаження даних у форматах CSV і XML. Для відновлення даних з таких форматів існує утиліта mysqlimport.
Утиліта mysqldump консольна. Існують її надбудови та аналоги, що дозволяють керувати бекапом через веб-інтерфейс, наприклад, українська тулза Sypex Dumper (їх представник є на хабрі).
Недоліки універсальних утиліт бекапу текстові файли- це відносно невисока швидкість роботи та відсутність можливості робити інкрементні бекапи.
3. Інкрементні бекапи
Традиційно рекомендують тримати 10 бекапів: по одному на кожен день тижня, а також бекапи двотижневої, місячної та квартальної давності - це дозволить досить глибоко відкотитися у разі псування будь-яких даних.Зберігатися бекапи повинні точно не на тому ж диску, що і жива база, і не на тому сервері. На випадок пожеж та інших катаклізмів найкраще орендувати пару юнітів у сусідньому дата-центрі.
Ці вимоги можуть стати проблемою великих баз. Прокачування бекапу 100-гігабайтної бази по 100-мбітній мережі займе години три, на які повністю заб'є канал.
Частково вирішити цю проблему дозволяють інкрементні бекапи, коли повний бекап робиться, скажімо, тільки в неділю, а в інші дні пишуться лише дані, додані або змінені за добу. Складність у тому, як виявити ці «дані, що змінилися за добу».
Тут практично поза конкуренцією система Percona XtraBackup, яка містить модифікований двигун InnoDB, аналізує двійкові логи MySQL і витягує з них необхідну інформацію. Майже такі ж можливості має платна InnoDB Hot Backup, згадана вище.
Загальна проблема з будь-якими бекапами в тому, що вони завжди відстають. У разі фатального збою основного сервера відновити систему можна буде лише з деяким «відкатом» за часом, що дуже розчарує її користувачів. Якщо в системі так чи інакше торкнулися фінансових потоків, подібний «відкат» може в прямому сенсі влетіти в копієчку.
Завантаження...