Что такое бэкап базы данных

Что такое бэкап базы данных

В данной статье мы рассмотрим примеры того, как можно сделать резервную копию (бэкап, backup) базы данных MySQL (или же определенной таблицы из этой базы).

Бэкап БАЗЫ (БАЗ) данных

Для создания резервных копий баз данных MySQL из терминала Linux, существует специальная утилита mysqldump, которая устанавливается вместе с сервером. Ниже рассмотрим несколько различных примеров, используя которые можно делать резервные копии как целых баз, так и необходимых таблиц в конкретной базе.

Создаем резервную копию ОДНОЙ базы

-u root — аргумент, означающий, что мы будем подключаться к MySQL серверу под учетной записью root (может быть любая учетная запись, имеющая необходимые права на нужную таблицу).
-p — аргумент, означающий, что необходимо ввести пароль для авторизации (т.е. доступ для данного пользователя без пароля — не разрешен). В случае, когда пароль не требуется, данный аргумент можно упустить.
database_name — это имя базы данных, резервную копию которой мы делаем.
database_name_backup.sql — это название бекапа, который будет создан. Создается он в текущем каталоге из которого вы запускаете данную команду. Если вам необходимо сохранить резервную копию в какой-либо определенный каталог, то можно сразу указать путь до этого каталога, написав вместо database_name_backup.sql , /tmp/database_name_backup.sql . Таком образом, резервная копия будет создана в каталоге /tmp

Создаем резервную копию НЕСКОЛЬКИХ баз

В случае, когда необходимо одной командой создать бекапы для нескольких баз данных, можно воспользоваться следующей командой:

—databases — аргумент, указывающий, что далее будут перечислены базы данных, резервные копии которых мы хотим сделать.
database_name_1 database_name_2 database_name_3 — имена баз данных, резервные копии которых мы хотим сделать. Разделяются пробелом.

Создаем резервную копию ВСЕХ баз

В случае, когда необходимо одной командой сделать резервную копию всех доступных баз данных, можно воспользоваться следующей командой:

—all-databases , аргумент, указывающий, что необходимо сделать резервную копию всех доступных баз данных.

Бэкап ТАБЛИЦЫ (ТАБЛИЦ) из определенной базы данных

Создаем резервную копию ОДНОЙ таблицы из базы

В том случае, когда у вас нет нужды создавать резервную копию всей базы данных целиком, а необходимо лишь создать резервную копию одной таблицы из этой базы данных, можно воспользоваться следующей командой:

table_name — это имя таблицы, резервную копию которой мы хотим сделать и которая находится в базе данных database_name .

Создаем резервную копию НЕСКОЛЬКИХ таблиц из базы

В том случае, когда вам необходимо сделать резервную копию нескольких таблиц из определенной базы, можно воспользоваться следующей командой:

table_name_1 table_name_2 table_name_3 — это названия таблиц, резервные копии которых мы хотим сделать. В нашем примере данные таблицы находятся в базе данных database_name .

Итак друзья, последнее время я занимаюсь всевозможными изысканиями в профессиональном плане, поэтому иногда статьи будут выходить сильно технического характера. Хотя ранее я тоже иногда баловался таким статьями, но теперь и тематика сайта к этому располагает и моя профессиональная деятельность.
У меня была беседа с друзьями, а они занимаются системным администрированием сетей. Так вот, они сильно были удивлены, и даже где-то расстроены, когда в подробностях узнали о том, на что способен SSH. А он способен делать в буквальном смысле ВСЁ!

Что такое скрипт?

Продолжая тему SSH, я хочу рассказать об использовании этого протокола для резервного копирования. Самая простейшая автоматизация бэкапов сайта или чего-либо ещё — это обычный скрипт.

В unix-системах таким файлам чаще всего задают расширение sh — от shell — оболочка. Но на самом деле это не имеет значения, такой файл может быть исполнен с любым именем и расширением или даже вообще без оного.

Зачем нужен скрипт для бэкапа?

Польза от такого формата очевидна — однажды написав скрипт, его можно выполнять многократно, причём автоматически и по расписанию. Именно это и требуется для решения задачи по созданию резервных копий. Бэкапирование сайтов и VPS поддерживается у многих хостеров, у некоторых по умолчанию, у некоторых это дополнительная услуга. Ведь для хранения бэкапов требуется дисковое пространство. Если проекты небольшие и бэкапы занимают несколько мегабайт, то это не создаёт проблем. Но если резервные копии ваших сайтов занимают несколько гигабайт, то бэкапить это становится сильно сложнее.

Хотя бы потому, что для сжатия в архив требуется больше ресурсов процессора и времени. Также и расход трафика становится неприлично большим. Хотя, сейчас его уже никто и не считает, но всё же передача данных занимает время.

В общем, задача понятна — надо бэкапить сайты. Файлы проектов и базы данных. Для решения оной существует множество способов, но в целом задача тривиальна — нужно место, куда класть бэкапы и нужна программа, которая это будет делать. Желательно автоматически.

На рынке есть много решений — платных, бесплатных, быстрых, сложных, простых, удобных, неудобных… Я же убежден, что наилучшим способом создания бэкапов являются самые простые и доступные в любой системе средства. То есть, обычное копирование это завсегда лучше, нежели какой-то хитрый формат архива, для восстановления которого понадобится дополнительная программа.

Этого достаточно, чтобы понимать нужен вам бэкап или нет. Тут я оставлю предложение для тех, кто не хочет вникать дальше, а просто недорого настроить резервное копирование.

Я принимаю заявки по контактам на vpsadm.ru. А ещё предлагаю воспользоваться новой интересной фриланс-платформой Kwork

Если вы с ней ещё не знакомы — рекомендую. Это биржа от компании Мирафокс, которую вы возможно уже знаете по другим проектам для вебмастеров (Telderi, Miralinks, Gogetlinks). На Kwork не фрилансеры побираются по размещенным потенциальным заказчиком предложениям, а сами выставляют предложения, которые заказчик может выбрать. «Фишка» сервиса — базовая стоимость любого кворка (так называют предложения фрилансеров) всегда 500 рублей.

Мой кворк по резервному копированию

А для тех, кто хочет разобраться во всём до конца и настроить самостоятельно — едем дальше.

Требования к бэкапам сайта

Итак, подведём промежуточный итог в виде требований к нашим резервным копиям:

  1. Бэкап должен содержать в себе всё, что нужно для восстановления проекта на любом другом сервере или хостинге. Бэкап должен быть удобным — самого простейшего доступного формата.
  2. Бэкап должен быть всегда под рукой.
  3. Бэкап должен храниться где-то далеко от основной работающей системы, на другом физическом носителе.
  4. Бэкап должен делаться максимально быстро и с наименьшими затратами ресурсов.

Дело за малым — создать такое решение. 2 и 3 пункты могут ввергнуть вас в когнитивный диссонанс, но сейчас дойдём до этого и станет понятней.

По первому пункту должно быть всё понятно, но всё же немного раскроем тему.

Какие части сайта нужно бэкапить?

Сайт обычно состоит из CMS и файлов. Мы не будем их разделять и пусть это будет одна составляющая — файлы.

Читайте также:  Где найти скопированную ссылку на андроиде

В каких-то особых случаях это можно или даже нужно разделять. К примеру, если мы имеем слишком большой объём или большое количество файлов самой CMS — нам нет смысла каждый раз бэкапить эту часть. Также встречаются варианты со всевозможными временными файлами, кэшами, которые также можно не копировать, ибо при восстановлении все эти части будут воссозданы, для нас не критична их потеря.

Но чаще всего сама CMS имеет небольшой объём относительно всего проекта, или в принципе. Поэтому проще сохранять в резерве всё подряд.

Как и чем делать бэкапы файлов сайта

В unix-системах, есть пару штатных средств которые лучше всего для этого подходят. Это архиватор — утилита tar, которая используется в связке с компрессором gzip.
tar zcfv backup-`date +%y%m%d`.tar.gz /var/www/myhosting/

На выходе получается архивный файл, в который упакованы сжатые файлы проекта.

Чем делать бэкапы большого размера?

При малом объёме данных такой подход себя оправдывает. Но если проект занимает сотни мегабайт или даже гигабайты — такой вариант очень плохо подходит для резервного копирования, поскольку сжатие будет занимать кучу времени и прилчно отъедать ресурсы системы. К счастью, в Linux имеется прекрасная штука rsync. Это утилита для синхронизации файлов. Это даже не просто утилита, а целый протокол, активно используемый для некоторых задач, но для нас интересна именно утилита. И что ещё важнее, она умеет работать поверх SSH, что нам пригодится в дальнейшем.

Простейший пример использования:
rsync -avh /var/www/site.com/ /var/backup/site.com

Эта команда полностью зеркалирует папку /var/www/site.com/ с папкой /var/backup/site.com. Я говорю — зеркалирует, потому что это не просто копирование, а именно синхронизация. Для неё характерны следующие особенности:

  1. Файлы переносятся как есть — с сохранением даты создания и изменения
  2. Файлы переносятся с сохранением владельца и прав
  3. В том случае, если во второй папке уже есть какие-то файлы из первой папки они не копируются.Сверяется их хэш и если файлы действительно совпадают — то они не перезаписываются.
  4. Имеет возможность не только копировать, но делать полную синхронизацию, с удалением из папки назначения тех файлов, которые исчезли из исходной директории. Требует предельной внимательности при использовании, но порой незаменима.

Как сделать бэкап базы данных сайта?

Вторая часть сайта, как правило, наиболее важная — база данных. Её потеря в большинстве случаев оказывается критичной, поэтому о бэкапах БД нужно заботиться в первую очередь. Если при потере файлов, мы ещё можем как-то извлечь их из кэшей, вебархивов, или просто воссоздать с нуля, то утеря базы данных, содержащей контент, сулит крах всего проекта.

Тут есть хорошая новость. Большинство хостеров регулярно делает резервные копии всех баз данных, которые у них хостятся на виртуальном (shared) хостинге.

Однако, в случае с ВПС/ВДС тут уже нельзя сказать так однозначно. Если вы держите свои сайты на отдельном виртуальном или выделенном сервере, то это предполагает, что вы сами в состоянии озаботиться такими вещами. Хостер же, банально может не иметь доступа к вашим БД и даже не знать об их существовании. Чаще всего так и происходит.

Для бэкапов БД существует также множество способов, но все они используют вот это:

mysqldump -u dbuser -p dbpass dbname > mysql-`date +%y%m%d_%H%M`.sql

Это и phpmyadmin, и панели управления вроде ISP и сторонние утилиты вроде Navicat. Все они используют штатные утилиты самой СУБД и работают поверх них. Однако, штатные утилиты имеют преимущество — бэкапы сохранённые с их помощью всегда гарантированно рабочие. Что же касается сторонних решений — тут надо только надеяться на то, что оно делает действительно целостный бэкап. В случае с mysql, на котором работают большинство сайтов — это утилита mysqldump. Если используется БД postgesql — команда будет выглядеть несколько иначе, но это тоже будет штатная утилита самой Postgres:

pg_dump -U user -Fc dbname > pgsql-`date +%y%m%d_%H%M`.dump

В данном случае используется специальный формат дампа — Custom, доступный в Postgresql. Он гораздо удобней обычного SQL, но таковой в постгрес тоже доступен — просто нужно выполнять эту команду без опций Fc.

Куда сохранять бэкапы сайта?

Близость бэкапа. Я предполагаю, что должен быть какой-то резерв с быстрым доступом. В качестве такого прекрасно подходит сам впс, на котором работает проект. Достаточно регулярно сбрасывать резервную копию на соседний диск или раздел, чтобы избежать большинства проблем с косяками программистов и дизайнеров, контент-менеджеров. А также проблем с шеллами, заражениями вирусами, взломами, угонами админки и прочими мелкими неприятностями и пакостями.

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

Тогда зачем это нужно? Представьте себе ситуацию. Нерадивый программист, решил что-то изменить в коде шаблона. Но ошибся и сайт перестал открываться. Он, конечно же, не сохранил исходный файл (потому и нерадивый) и теперь не помнит как это вернуть обратно. Он надеялся что фатальной ошибки не будет, что тут надо просто подправить пару функций и переменных и… сайт ложится и не открывается. Программиста прошибает пот… Да это может быть и не программист, а вы сами. У меня такое случается, например. Уж я-то ведь точно знаю что делаю, что ничего плохого не случится, если я уберу вот эти пару строк кода и вот здесь тоже сменю параметр… Упс.

Как настроить автоматический бэкап сайта по расписанию?

Но меня не прошибает пот. Потому что файлы всех сайтов на впс сбрасываются в соседнюю папку, каждые два часа. А если вирусы или взломали сайт? это ведь можно заметить гораздо позднее, чем через 2 часа, тогда в бэкапе тоже будут испорченные данные. Верно. Поэтому есть ещё одна папка, куда сбрасываются все файлы раз в 3 дня. У меня записано в crontab:

0 */2 * * * rsync -avh /var/www/ /var/h2backup/ #бэкап делается каждые 2 часа
0 1 */3 * * rsync -avh /var/www/ /var/d3backup/ #раз в три дня в час ночи

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

Но ведь это увеличивает объем файлов в 3 раза. Да, увеличивает. Но бэкапов много не бывает, друзья 🙂 Других способов на 100% обезопасить себя от вышеперечисленных неприятностей я не знаю. Если самому можно быть просто аккуратней и внимательней при правке кода, сохранять копию файла перед редактированием , то при работе команды это становится невозможным. И чем больше команда, тем больше верятности, что где-то кто-то накосячит. Что уж говорить о кулхацкерах и вирусах.

Читайте также:  Как заблокировать приложение на телефоне самсунг

Оно и понятно, если человек подвергался таким атакам — у него может возникнуть паранойя.

Я же просто делаю два бэкапа — раз в два часа и раз в три дня. Я не обвешиваю многострадальный wordpress подобной «атрибутикой», потому что никакие атаки просто не способны повредить сайтам — я всегда все могу восстановить и откатить в считанные минуты.

Поэтому все извращения, вроде «WP security all in one» c htaccess’ами в сотни строк, у меня ничего, кроме улыбки, не вызывают, друзья 🙂

Надеюсь по этому пункту всё понятно.

Зачем сохранять бэкапы на удалённое хранилище?

Пункт о том, что бэкап также должен храниться далеко от хостинга. А это уже совсем форс-мажорные ситуации. Когда проблема у хостера. Понятно, что от такого хостера надо бежать скорей, но лучше иметь при этом бэкап где-то подальше от него. Или когда проблема у вас — кто-то настучал хостеру, а тот закрыл доступ без предупреждения. Всякие ведь проекты бывают, чего греха таить. А может и не закрыл, может DDOS’ят, да так, что хостингу, что называется, «ни дохнуть, ни пукнуть», простите, и ваш проект терпит убытки по причине недоступности. Имея бэкап вне хостинга вы бы могли быстренько развернуть его у другого хостера, перенаправить DNS и снизить даунтайм и убытки. А то ведь особо тщательно спланированный DDOS и по нескольку дней может длиться, знаете ли.

Это значит, нужно сохранять свои данные на каком-то облачном хранилище, или, на худой конец, на своём рабочем или домашнем компьютере — это доступно всем без исключения. Особенно, учитывая, что где, как не на личном компьютере, у нас есть сотни гигов, а то и терабайты диска, бесполезно простаивающие или забитые каким-нибудь хламом 🙂 Кстати, именно такая ситуация стала предпосылкой к написанию всего этого талмуда. Один мой знакомый озадачился бэкапированием сайта, в 50 гб объёмом, на свой домашний компьютер. И обратился за помощью ко мне. Подумали, потестировали, и родилось решение — как делать бэкап по SSH на компьютер с Windows.

Если у нас имеется другой ВПС — то можно бэкапить данные на него без особых трудностей. rsync придётся здесь как нельзя кстати. Сделайте авторизацию по ключу, добавьте пару строк в вашем crontab c нужной периодичностью — и можно забыть про бэкапы. Точно также можно сделать и для хранения бэкапов на домашнем компьютере, если там стоит Linux или FreeBSD.

Как бэкапить сайт по SSH на домашний компьютер Windows?

Но вот в случае с Windows придётся заморочиться. Для этого потребуется утилита plink.exe. Получить её можно на putty.org по ссылке here. Она позволяет использовать ssh из командной строки винды. Это маленькая но крайне полезная штуковина поможет создать те самые скрипты для автоматического бэкапа.

Просто создайте текстовый файл с такими строками:

d:plink.exe -pw rootpassword root@example.com -C "mysqldump -uroot -ppassword sitedb|gzip">d:ackupsitedb-%date%.gz
d:plink.exe -pw rootpassword root@example.com -C "tar czfv — /var/www/example.com/">d:ackupexample_com-%date%.tar.gz

здесь rootpassword — это пароль ssh, а -uroot пользователь БД — -uuser, например. -ppassword — пароль этого пользователя, соответственно — —pyourpass, sitedb — имя БД сайта. Здесь не пугайтесь, mysql поддерживает опции слитно со значениями, но можно и поставить пробел — -u user и -p password.

И сохраните файлик с расширением bat. Теперь, запустив этот файлик двойным кликом вы получите бэкап базы данных и сайта в указанную папку.

сохранение в bat

Этот же скрипт можно создать через наш генератор скритов для бэкапов.

Как настроить автоматические бэкапы в Windows?

Очень просто — нужно использовать штатный планировщик для запуска скрипта.

Нажмите win+R и запустите taskschd.msc:

Запуск планировщика Windows

В меню «действие» выберите «Создать задачу»:

В первой вкладке у вас будет обязательное поле для произвольного имени задачи. Затем выберите вкладку «действия» и укажите путь к своему скрипту:

Перейдите на вкладку «Триггеры» и задайте расписание:

Вы можете настроить здесь любую периодичность.

Теперь перейдя в раздел «Библиотека планировщика» вы можете убедиться, что ваша задача создана.

Это самый простой способ бэкапировать сайт на домашний компьютер. Всё что вам нужно — это доступ к хостеру по SSH и утилитка plink. Но будьте внимательны, если забыть об этом на пару месяцев, вы можете очень удивиться, когда на вашем диске закончится свободное пространство 🙂 Поэтому заглядывайте в папку, куда вы настроили сохранение резервных копий и удаляйте старые бэкапы. Этот метод отлично подходит для небольших проектов в несколько мегабайт.

Как избежать переполнения и как быть, если вам нужно бэкапить большие объёмы данных? Об этом расскажу обязательно, но в следующий раз. Подписывайтесь на новые статьи, друзья, и вы этого не пропустите!

Что такое backup и зачем нужен

Резервная копия сайта (backup) – это процедура копирования и сохранения файлов сайта, баз данных, настроек аккаунтов, SSL-сертификатов и прочих данных, относящихся к сайту, в месте отличном от места размещения самого сайта. Например, на локальный компьютер или на специальный сервер для резервных копий.

Бэкап позволяет восстановить работоспособность сайта (или его состояние на какой-то момент) в случаях:

  • Заражения вирусами;
  • Взлома сайта злоумышленниками;
  • Случайного удаления файлов или страниц сайта (или их части);
  • Потери данных из-за ошибок оборудования;
  • Потери или нежелательные изменения данных из-за неверных действий администратора или владельца сайта;
  • Глобальной аварии у хостера;
  • Различных конфликтных ситуаций с вашим хостинг-провайдеров, приводящих к блокировке или удалению аккаунта.

При наличии грамотного резервного копирования в случае любых проблем работу сайта можно восстановить за несколько минут (или пару-тройку часов в особо тяжелых случаях).

Примечание: чтобы снизить риски различных блокировок – держите домен и хостинг у разных компаний.

Как часто делать резервные копии

Вопрос частоты резервного копирования очень индивидуален. Все зависит от вашего бизнеса и критичности потери данных.

Если у вас просто сайт-визитка компании, данные на котором почти не меняются, то вполне можно обойтись одним полным бэкапом в месяц.

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

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

Читайте также:  Лучшие утилиты для очистки компьютера

Как и чем делать бэкапы сайта

Ответ на этот вопрос на самом деле следует из предыдущего раздела. Всё индивидуально. Мы же можем дать только общие рекомендации.

Но давайте предположим, что у нас среднего размера проект, который имеет ежедневное обновление контента, но при этом не содержит критически важных данных.

Резервное копирование средствами хостинга

Большинство популярных провайдеров виртуального хостинга предоставляют на всех тарифах автоматическую систему резервного копирования.

Бэкапы обычно делаются за относительно небольшой промежуток времени, чаще всего за последние 7 дней. Бэкапятся полностью все файлы и базы данных на аккаунте.

  • Beget. Из панели управления – раздел «BackUp». Одна копия по требованию бесплатно, последующие – 2 руб.

  • Timeweb. Панели управления главное меню слева – раздел «Резервные копии». Бэкап по требованию платно – 5 руб. за копию.

  • Sprinthost. Левое меню панели управления – раздел «Дополнительно» – пункт «Резервные копии». Все бэкапы у Спринтхост бесплатные.

  • Хостинги на ISPmanager. В панели управления левое меню – раздел «Резервное копирование». Периодичность и цена дополнительных бэкапов будут зависеть от конкретного хостинга.

  • Хостеры под управлением CPanel. На главном экране панели управления в секции «Files» («Файлы») – значок «Site Backup». Обычно ручные копии бесплатные.

Резервное копирование вручную

Сделать ручной бэкап также обычно несложно. Самый простой способ – воспользоваться файловым менеджером хостинга для создания архива файлов и через phpMyAdmin сделать дамп базы данных.

Некоторые хостеры также дают возможность сделать бэкап по запросу через панель управления или скачать ранее автоматически созданный архив.

Главное, не забудьте потом скачать все созданные архивы к себе на компьютер, а с хостинга их удалить после этого.

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

Отличный способ делать бэкапы так, как нужно именно вам, и при этом не делать все вручную – это создать свой собственный скрипт резервного копирования и запускать его по расписанию. А резервные копии сохранять на файловый сервер у другого провайдера или в какой-нибудь облачный сервис.

Мы часто используем простой bash-скрипт – он выполняет полное копирование раз в заданные промежуток времени, а в промежутках делает бэкапы только измененных файлов. А все архивы сохраняет на удаленный FTP-сервер.

Делимся скриптом, можете использовать под свои нужды:

Резервное копирование средствами CMS

Некоторые системы управления сайтами имеют модули или встроенные функции для создания бэкапа сайта.

Рассмотрим возможности резервного копирования у некоторых популярных CMS.

Резервное копирование в WordPress

Для WordPress существует несколько как платных, так и бесплатных модулей для бэкапов.

  1. BackUp WordPress (http://wordpress.org/plugins/backupwordpress/)
    Позволяет делать резервные копии файлов и базы данных. В платной версии можно сохранять архивы в Google Disk или Dropbox.
  2. WP Remote – плагин и сервис (https://wpremote.com/)

    В бесплатной верcии только ручное копирование. В платной работа по расписанию и интеграция с Driopbox и Amazon S3.
  3. UpdraftPlus (https://ru.wordpress.org/plugins/updraftplus/)

    Очень прост в использовании. Копии может хранить в каталоге сайта или в обачном хранилище (Google Диск, Dropbox, Amazon S3 и др.). Бесплатная версия полностью функциональна. В платном варианте только добавляется поддержка других облачных хранилищ.

Для WordPress существует еще несколько плагинов для резервного копирования, но даже указанных выше уже более чем достаточно для большинства сайтов.

Резервное копирование в Drupal

CMS Drupal имеет очень мощный бесплатный модуль Backup and Migrate. Модуль позволяет очень гибко настраивать какие части вашего сайта бэкапить, делать резервные копии базы данных.

Все это возможно настроить по расписанию, делать копирование одновременно в различные хранилища. Возможно удаленное копирование по FTP, сохранение копий локально, хранение копий с специальном защищенном каталоге прямо на сайте, бэкапы в хранилища Amazon S3.

С помощью дополнительных расширений можно архивы по защищенному протоколу SFTP и сохранять свои резервные копии в облако DropBox.

Кроме того «из коробки» интегрирован с сервисом NodeSquirrel, предоставляющим 5 Гб. бесплатно для для одного сайта на аккаунте.

Резервное копирование в CMS Bitrix

Самая популярная система для сайтов в России Битрикс тоже имеет встроенные средства для создания бэкапов.

Битрикс позволяет настроить, какие именно части сайта нужно бэкапить. Делать копии базы данных. Исключать ненужные данные из бэкапа.

Хранить архивы Битрикс предлагает или в каталоге сайта, или в собственном облаке компании 1С-Битрикс.

Где хранить резервные копии

Вариантов мест для хранения бэкапов очень много. Приведем список самых часто используемых хранилищ:

# Вариант хранения Наш комментарий
1 В каталоге с сайтом Обычно используется для быстрых копий перед внесением изменений в контент сайта, чтобы можно было быстро откатиться назад
2 В каталоге аккаунта на хостинге «рядом» с сайтом Обычно это «промежуточный» способ, часто используется при переносе сайта с одного сервера на другой
3 Файловые хостинги Специальные хостинги для хранения только статичных сайтов. Обычно предоставляют много дискового пространства за небольшие деньги. Передача файлов производится по FTP, SFTP или методом S3
4 Специализированные сервисы для хранения резервных копий Например, облако 1С-Битрикс или NodeSquirrel и тп.
5 Хранение на другом сервере или хостинге Довольно сомнительный метод на наш взгляд, но он имеет место быть. Суть в том, что если у вас есть 2 разных сайта на разных хостингах (или хотябы на разных серверах одного), то копии 1-го сайта вы храните на 2-м хостинге, а копии 2-го сайта на 1-м хостинге – такое себе «перекрестное опыление» бэкапами
6 Локальный диск Вы просто скачиваете backup-архив к себе на компьютер и храните либо прямо там или копируете еще на какой-то носитель (сетевой или съемный). Этот способ самый неудобный, но иногда всеже стоит сохранять архив локально, как показывает практика, такая перестраховка иногда бывает очень кстати

Резервное копирование виртуальных серверов

Если вы арендуете VPS или VDS, то все заботы по резервному копированию ложатся полностью на ваши плечи. При этом все вышеперечисленные способы, кроме средств панели управления хостингом, в полной мере остаются актуальными и для виртуальных серверов.

А вот резервное копирование средствами хостера для VPS/VDS предоставляют далеко не все провайдеры. И обычно это дополнительная платная услуга.

Например дополнительно систему резервного копирования сервера можно заказать у 1cloud.ru и у cloudlite.ru, а AdminVPS в зависимости от тарифа предоставляет от 20 до 160 Гб дискового пространства под backup бесплатно.

Подводя итоги

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

Частота резервного копирования должна соотноситься с масштабами и задачами вашего проекта.

А хранить резервные копии лучше всего минимум в двух независимых друг от друга хранилищах.

Ссылка на основную публикацию
Что значит код ошибки 805а8011
Многие владельцы смартфонов с операционной системой Windows Phone не могут войти в учетную запись магазина Marketplace. На экране появляется код...
Хочу создать группу в контакте
Приветствую вас, дорогие читатели. Социальные сети уже давно вошли в нашу жизнь, поэтому всем владельцам абсолютно любого бизнеса, как традиционного,...
Хром для андроид тв приставок
Всем привет! Предлагаю очередной раз поднять больную тему браузеров для Android TV. В разделе «вопрос – ответ» уже много раз...
Что значит интегрированный процессор
Здравствуйте, уважаемые пользователи и любители компьютерного железа. Сегодня порассуждаем на тему, что такое интегрированная графика в процессоре, зачем она вообще...
Adblock detector