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

В общем, чтобы спать спокойно, нужно обеспечить периодическое сохранение содержимого БД вне рабочего сервера на случай, если по каким-то причинам доступ к содержимому сервера будет утерян. Для тех, кто (как и я) не дорос еще до репликаций БД на отдельных серверах, мой ответ — отправляйте дампы по почте.

Не буду рассказывать здесь, что возможны альтернативные (возможно более правильные) способы достичь того же эффекта. Здесь описано то, как это сделал я, какие встречались грабли.

Итак, весь процесс условно делится на три части:

  1. дамп БД в локальную папку, его архивирование
  2. отправка архива по почте
  3. создание bash-скрипта и задания cron, с нужной периодичностью выполняющего этот скрипт

Наша ОС — Ubuntu.
Наша СУБД — Postgresql.

1. Сохраняем локально


Допустим:

  • имя юзера СУБД — postgresuser
  • пароль юзера СУБД — userpass
  • название резервируемой БД — mydatabase
  • путь к папке для локального сохранения — /tmp
  • имя файла для локального сохранения — pg_dump.sql (после архивации получиться pg_dump.sql.gz)

Если мы сейчас попытаемся выполнить команду дампа…

pg_dump -U postgresuser -h localhost --inserts mydatabase | gzip > /tmp/pg_dump.sql.gz

… то скорее всего терминал запросит у Вас пароль. Но это нас не устраивает, т.к. данная команда будет выполняться автоматически в bash-скрипте, и хотелось бы, чтобы пароль подставлялся сам.

Для этого в домашней папке Ubuntu-юзера (допустим — sergey) создаем скрытый файл .pgpass. На всякий случай, это будет выглядеть вот так:

/home/sergey/.pgpass

Открываем этот файл и вставляем одну строчку:

localhost:5432:mydatabase:postgresuser:userpass

… где

  • postgresuser — имя юзера СУБД
  • userpass — пароль юзера СУБД
  • mydatabase — название резервируемой БД

Теперь команда…

pg_dump -U postgresuser -h localhost --inserts mydatabase | gzip > /tmp/pg_dump.sql.gz

… должна завершиться созданием архива pg_dump.sql.gz в папке /tmp.

ERRORS: Возможно появление ошибок, связанных с разрешениями на БД, которые возникают из-за того, что пользователь postgresuser не имеет права на БД mydatabase. Нужно ему их предоставить.

2. Отправляем архив по почте


Не буду рассказывать об истории и разнообразии почтовых клиентов под Linux (тем более что сам не знаю). Короче, ставите mutt.

sudo apt-get install mutt

В домашней папке Ubuntu-юзера (а мы помним, что это — /home/sergey/, и там еще лежит файл .pgpass) создаем скрытый файл .muttrc и вставляем внутрь файла примерно следующее:

set from = moya_pochta@gmail.com
set imap_user = moya_pochta@gmail.com
set imap_pass = "pochtapass"
set smtp_url = smtp://moya_pochta@smtp.gmail.com:587/
set smtp_pass = "pochtapass"
# don't let your firewall kill your idle connection
set imap_keepalive  = 900
# do not copy sent mail
set copy = no
set move = no 
set folder = imaps://imap.gmail.com:993
set spoolfile = +INBOX #or +[Gmail]/Important
set postponed = +[Gmail]/Drafts
# cache
set header_cache    = ~/.mutt/cache/headers
set message_cachedir    = ~/.mutt/cache/bodies
set certificate_file    = ~/.mutt/certificates

… где
— moya_pochta@gmail.com — адрес, ОТКУДА будут отсылаться дампы;
— pochtapass — пароль от этой почты.

Если у Вас почта Yandex, то в 4-й строчке вместо gmail.com вставляете yandex.ru, и все будет работать.

Пробуем отправлять наш файл:

mutt -s "Dump" -a /tmp/pg_dump.sql.gz -- drugaya_pochta@gmail.com < /dev/null

Здесь:

  • «Dump» — тема письма
  • /tmp/pg_dump.sql.gz — наш дамп
  • drugaya_pochta@gmail.com — адрес, КУДА будут отсылаться дампы

ERRORS: Вы можете получить следующею ошибку — SASL authentication. Это значит, что не удалось войти в почту-отправитель (это которая — moya_pochta@gmail.com). Причин я насчитал три:

  1. неправильный логин и/или пароль;
  2. на почтовом аккаунте не разрешен доступ непонятным приложениям (типа mutt). Если у вас gmail, то нужно включить доступ к аккаунту для непроверенных приложений, вот здесь;
  3. ХЗ. Например, у меня не получилось пробиться к одному конкретному аккаунту gmail через mutt, хотя изменил разршения доступа и перепроверил логин и пароль. Другие аккаунты отлично работают, причем и gmail и яндекс.почта.

3. Автоматизируем


Для начала пишем скрипт pg_mutt.sh и кладем вот сюда /home/sergey/ (в данном случае не важно — куда).

#!/bin/bash
EMAIL="drugaya_pochta@gmail.com"
DATABASE="mydatabase"
DATE=$(date +"%Y-%m-%d")
FILE="/tmp/pg_dump_${DATABASE}_$DATE.sql.gz"
pg_dump -U postgresuser -h localhost --inserts $DATABASE | gzip > $FILE
mutt -s "Dump $DATABASE $DATE" -a $FILE -- $EMAIL < /dev/null

Здесь Вам нужно заменить drugaya_pochta@gmail.com, mydatabase, postgresuser на свои данные.
Делаем файл pg_mutt.sh исполняемым:

chmod +x pg_mutt.sh

Создаем задачу cron, чтобы срабатывало каждое воскресенье в 3.00:

crontab -e

0 3 * * 0 /home/sergey/pg_mutt.sh

Заключение


Обязательно периодически проверяйте содержание того, что приходит в виде файла с названием pg_dump_mydatabase_*.sql.gz, потому что может так получиться, что Вы вроде теперь спите спокойно, а не следовало бы.
Поделиться с друзьями
-->

Комментарии (18)


  1. ky0
    26.09.2016 13:22
    +9

    Ну, признавайтесь, кто дал за это инвайт?


  1. ssssergey
    26.09.2016 13:25
    -2

    Тому спасибо.


  1. BOOMER_74
    26.09.2016 15:16

    PHPBU. Конечно, написано на PHP, но функциональнее и удобнее будет.


  1. OLQLOSH
    26.09.2016 15:57

    не получилось пробиться к одному конкретному аккаунту gmail через mutt, хотя изменил разршения доступа и перепроверил логин и пароль


    Это скорее из-за того, что не отключена капча. Отключается по ссылке http://www.google.com/accounts/DisplayUnlockCaptcha

    Когда-то тож извращался таким образом и пришел к выводу, что отправка дампов через почту оч плохое занятие. А если бд будет весить больше некоторого размера и отправка по почте будет невозможна? Если уж используете gmail, то попробуйте воспользоваться гугл-диском для хранения бэкапов. Есть несколько консольных клиентов — gdrive, к примеру, или google-drive-ocamlfuse. Вот тут я описывал, как прикрутить гугл-диск к linux и сливать на него бэкапы.


    1. ssssergey
      26.09.2016 16:17
      -1

      Да, согласен, что это костыль. Но мне его пока достаточно. За совет спасибо. Нужно будет изучить этот вариант. А с какого размера БД, по вашем мнению, уже стоит прекращать использовать почту?


      1. OLQLOSH
        26.09.2016 16:24

        В суппорте гугла написано, что к сообщению можно прикрепить файлы, суммарный объем которых не превышает 25 МБ. Вот ссылка


        1. stigory
          27.09.2016 08:05

          Уточню. Ваша ссылка о разрешенном размере для отправляемых писем. Для принимаемых размер следующий:


          250-mx.google.com at your service, [162.243.85.20]
          250-SIZE 157286400

          Т.е. около 100Мб можно пропихнуть


    1. Cubus
      27.09.2016 10:42

      Можно использовать Яндекс-Диск: http://dba-notes.org/2012/04/27/%d0%bf%d1%80%d0%be%d1%81%d1%82%d0%be%d0%b9-%d0%b1%d1%8d%d0%ba%d0%b0%d0%bf-%d0%bd%d0%b0-%d1%8f%d0%bd%d0%b4%d0%b5%d0%ba%d1%81-%d0%b4%d0%b8%d1%81%d0%ba-%d1%81-%d0%bf%d0%be%d0%bc%d0%be%d1%89%d1%8c%d1%8e-c/
      Там WebDAV, всё предельно просто.


      1. OLQLOSH
        27.09.2016 11:29

        Вариантов может быть множество. Можно использовать еще и такую штуку http://cloudcross.mastersoft24.ru/ru/ и слать на дропбокс. Автор поста использовал для своих действий аккаунт гугла, поэтому и написал про гугл-диск.


  1. alexrett
    26.09.2016 16:20
    +5

    Репликации — это конечно не про всех, но слать дампы на почту… Мсье знает толк…


  1. celebrate
    26.09.2016 21:24
    +3

    Ну, чувствую, пахнет стартапом ))


  1. Pilat
    27.09.2016 01:55

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


  1. darken99
    27.09.2016 11:01

    Уберите тег "резервное копирование" и не позорьтесь


    1. ssssergey
      27.09.2016 11:13
      -1

      Резервное копирование (англ. backup copy) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.
      Резервное копирование необходимо для возможности быстрого и недорогого восстановления информации (документов, программ, настроек и т. д.) в случае утери рабочей копии информации по какой-либо причине.


      1. ssssergey
        27.09.2016 11:17

        "


    1. ssssergey
      27.09.2016 11:19

      А тэг к статье указан — «резервирование данных»


  1. point212
    28.09.2016 00:44

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

    ЗЫ самый маленький дамп у меня в хозяйстве сейчас — 36Гбайт. Он только отправляться по почте будет пару часов. При этом ещё и положит исходящий канал.

    Короче статья если и подходит кому -то, то скорее для бэкапа своих мелких сайтиков, форумов и бложиков.


    1. ssssergey
      28.09.2016 01:51

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