Простой способ резервного копирования Linux-сервера с выгрузкой файлов по FTP

    Здравствуйте.
    О важности регулярного резервного копирования уже сказано очень много слов. В этой статье мы предлагаем вниманию читателей примеры простых скриптов для бэкапа файлов и баз данных MySQL с последующей выгрузкой архивов на удаленный FTP-сервер.
    Несмотря на то что мы в NQhost предлагаем решения по сохранению snapshot'ов VPS-контейнеров, процесс бэкапа собственными силами — безусловно важнейшая вещь.


    Хозяйство


    Виртуальный или физический сервер с установленной Linux-ОС, веб-сервером и базами данных MySQL.
    Файлы веб-сервера располагаются в директориях
    /home/site1
    /home/site2
    /home/site3

    Задача


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

    Решение


    Для простоты примера работать мы будем из-под root`а, директория для хранения бэкапов файлов — /root/backup/server, а для дампов MySQL — /root/backup/mysql

    Backup файлов

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

    #!/bin/sh
    ### System Setup ###
    BACKUP=/root/backup/server

    ### FTP ###
    FTPD="/"
    FTPU="username" [имя пользавателя (логин) удаленного ftp-cервера]
    FTPP="megapassword" [пароль доступа к удаленному ftp-серверу]
    FTPS="my_remote_backup.ru" [собственно, адрес ftp-сервера или его IP]

    ### Binaries ###
    TAR="$(which tar)"
    GZIP="$(which gzip)"
    FTP="$(which ftp)"

    ## Today + hour in 24h format ###
    NOW=$(date +%Y%m%d) [задаем текущую дату и время, чтобы итоговый файл выглядел в виде server-YYYYMMDD.tar.gz]

    ### Create tmp dir ###

    mkdir $BACKUP/$NOW
    $TAR -cf $BACKUP/$NOW/etc.tar /etc [c целью сохранения настроек для простоты копируем весь /etc ]
    $TAR -cf $BACKUP/$NOW/site1.tar /home/site1/
    $TAR -cf $BACKUP/$NOW/site2.tar /home/site2/
    $TAR -cf $BACKUP/$NOW/site2.tar /home/site3/

    ARCHIVE=$BACKUP/server-$NOW.tar.gz
    ARCHIVED=$BACKUP/$NOW

    $TAR -zcvf $ARCHIVE $ARCHIVED

    ### ftp ###
    cd $BACKUP
    DUMPFILE=server-$NOW.tar.gz
    $FTP -n $FTPS <<END_SCRIPT
    quote USER $FTPU
    quote PASS $FTPP
    cd $FTPD
    mput $DUMPFILE
    quit
    END_SCRIPT

    ### clear ###

    rm -rf $ARCHIVED


    Результатом работы данного скрипта будет созданный файл в директории /root/backup/server вида server-ГГГГММДД.tar.gz содержащий в себе tar-архивы директорий /etc, /home/site1, /home/site2 и /home/site3
    Этот же файл будет загружен на FTP-сервер, который мы указали в начале скрипта.

    Backup баз MySQL

    Этим скриптом мы выгружаем базы данных MySQL (делаем т.н. «дампы). Каждая база выгружается в отдельный файл.

    #!/bin/sh
    # System + MySQL backup script
    ### System Setup ###
    BACKUP=/root/backup/mysql

    ### Mysql ### [параметры доступа к нашим базам MySQL]
    MUSER="root"
    MPASS="megapassword"
    MHOST="localhost"

    ### FTP ###
    FTPD="/"
    FTPU="username" [имя пользавателя (логин) удаленного ftp-cервера]
    FTPP="megapassword" [пароль доступа к удаленному ftp-серверу]
    FTPS="my_remote_backup.ru" [собственно, адрес ftp-сервера или его IP]

    ### Binaries ###
    TAR="$(which tar)"
    GZIP="$(which gzip)"
    FTP="$(which ftp)"
    MYSQL="$(which mysql)"
    MYSQLDUMP="$(which mysqldump)"

    ## Today + hour in 24h format ###
    NOW=$(date +%Y%m%d)

    ### Create temp dir ###

    mkdir $BACKUP/$NOW

    ### name Mysql ###
    DBS="$($MYSQL -u $MUSER -h $MHOST -p$MPASS -Bse 'show databases')"
    for db in $DBS
    do

    ### ###
    mkdir $BACKUP/$NOW/$db
    FILE=$BACKUP/$NOW/$db/$db.sql.gz
    echo $i; $MYSQLDUMP --add-drop-table --allow-keywords -q -c -u $MUSER -h $MHOST -p$MPASS $db $i | $GZIP -9 > $FILE
    done

    ARCHIVE=$BACKUP/mysql-$NOW.tar.gz
    ARCHIVED=$BACKUP/$NOW

    $TAR -zcvf $ARCHIVE $ARCHIVED

    ### ftp ###
    cd $BACKUP
    DUMPFILE=mysql-$NOW.tar.gz
    $FTP -n $FTPS <<END_SCRIPT
    quote USER $FTPU
    quote PASS $FTPP
    cd $FTPD
    mput $DUMPFILE
    quit
    END_SCRIPT

    ### clear ###

    rm -rf $ARCHIVED


    Результат работы скрипта — файл в директории /root/backup/server вида mysql-ГГГГММДД.tar.gz содержащий в себе tar-архивы c дампами всех баз данных и его выгрузка на FTP-сервер.

    Автоматизация

    Сохраняем данные скрипты в директорию /etc/cron.daily, предварительно проверив в файле /etc/crontab, что именно из этой директории запускаются скрипты каждый день.

    Заключение


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

    NQhost

    0,00

    Компания

    Поделиться публикацией

    Похожие публикации

    Комментарии 26
      +4
      Вы бы лучше упомянули, как заливать на удаленный ftp ~20Gb бэкап варьируя скорость аплоада в зависимости от нагрузки сети.
        0
        Это уже достаточно частный случай, статья все-таки об основах организации процесса.
          +2
          Ну как, «частный»? Даже небольшой файл в нужный момент может сделать проблемы.
          +1
          Для этого наверное rsync подойдет
          --bwlimit=KBPS limit I/O bandwidth; KBytes per second
          +3
          mysqldump на сколько-нибудь большой да еще и живой базе обрадует вас очень долгим бэкапом и прочими прелестями.
          Для MyISAM лучше использовать mysqlhotcopy, для InnoDB Percona XtraBackup (он и MyISAM может, но если надо только MyISAM то mysqlhotcopy гораздо проще).
            +1
            Спасибо за комментарий. Конечно, в каждом конкретном случае к вопросу надо подходить исходя из актуальной ситуации на сервере.
            Данная статья — это в первую очередь призыв новичкам организовать процесс резервного копирования.
              0
              пока в голове не пронесутся пару дней похеренно работы, никто ничего не будет делать, а если и будет, то не будет проверять целосность бекапа.

              целосность и тестирование на целосность это по-моему самая большая проблема в создании бекапа, а вот про это как раз и не хватает статьи
            +2
            Пойду перепишу свои костыли для этой задачи. Автор, спасибо за статью! =)
              +2
              Пожалуйста. Рады, что статья оказалось полезной.
              +2
              Чего только люди не сделают, чтобы bacula не настраивать (:
                0
                Было бы очень интересно почитать о способах организации инкрементальных бекапов. Так как часто тратить по 20Гб и более в день трафика на бекапы не всегда возможно.
                  +1
                  а чего там сложного? можно тем же таром:
                  tar czvf /root/VPSbackups/VPSbackup.tar.gz -N"$LAST" --exclude-from=/VPSbackups/tar.excludelist.txt /etc/ /root/exportdb/ /home/username/ > /root/VPSbackups/backup.log 2>&1
                  ##где tar.excludelist.txt - список исключений;
                  ##а LAST - файл с датой в формате date +'%F %R:%S'
                  LAST=`cat /root/VPSbackups/lasttimebackup.log`
                  
                    0
                    Хм, действительно, что-то я об этом не подумал. То, что надо. А то у меня всё была идея делать какие-то бинарные дифы и прочее… а всё оказывается гораздо проще. Спасибо!
                      0
                      Пожалуйста, у меня например, раз в неделю полный бекап, а потом каждый день инкрементальные по дате когда был полный. Думаю, список файлов для тарирования тоже можно вынести в отдельный файл, если он большой.
                  0
                  что-то мне подсказывает, что
                  mput $DUMPFILE
                  по дефолту работать не будет.
                  при mput спрашивается подтверждение на имя файла.
                  правильнее
                  put $DUMPFILE
                    0
                    либо добавить «prompt», который укажет клиенту не запрашивать подтверждения.
                    0
                    А я для пересылки бекапов использую scp с аутентификацией по ключу. Как по мне, это удобнее и безопаснее.

                    Скорость канала, кстати, можно отрегулировать при помощи CBQ или аналогичных.
                      0
                      В Debian есть утилита backup-manager, умеет инкрементальные бекапы, отправку на удаленный FTP, SSH, RSYNC, Amazon S3. Написана на Perl. www.backup-manager.org/about/
                        0
                        А я делаю так:
                        #!/bin/bash

                        cd /home/Backup
                        # Бэкап всего что нужно
                        tar -cvvzf /home/Backup/back-`date '+%m_%d_%Y'`.tar.bz2 \
                        /var/www/ \
                        /var/lib/mysql/ \
                        /etc/ \
                        /var/log/ \
                        /root/ \
                        --exclude=/home/Backup > ./last.log

                        # Стираем файлы бэкапа старше 30 дней
                        find . -mtime +30 -exec rm '{}' \;
                        # Стираем старые логи
                        find /var/log/ -type f -name *\.gz -exec rm '{}' \;


                        А с директорией /home/Backup можно делать что угодно, например с Dropbox ее синхронизировать. У меня сервер не большой, суточный бэкап ~300Мб, а за месяц около 10гигов.
                        Запуск по крону каждую ночь, понятно.
                          0
                          Dropbox на сервере или на десктопе?
                            0
                            Бэкапы сервера синхронизирую через десктоп в ручном режиме, но это из-за не желания покупать 10 гигов на dropbox — обхожусь спокойно 2мя бесплатными.

                            Ну а вообще, у dropbox при установке заводится на машине демон и нет проблем синхронизировать всю директорию.

                            Я ответил на ваш вопрос?
                          –1
                          Заголовок не соответствует статье — бэкап всея сервера подразумевал, подразумевает и подразумевать будет сохранение / со всеми симлинками-датами-специальными файлами-специальными атрибутами.

                          Бэкап данных + конфигов + пользователей + системы == бекап сервера.
                            0
                            Раз все так элементарно, то почему вы не внедрили ранее backup в своих услугах и как минимум полгода кормили обещаниями мол очень скоро? ) (что собственно и стало причиной отказа от услуг)
                              0
                              В этой статье мы рассказываем о самостоятельном резервном копировании.
                              А централизованный backup мы, кстати, внедрили тоже.
                              Возвращайтесь :)
                                0
                                хороша ложка к обеду )
                              0
                              При коннекте к FTP нужно переходить в режим binary, иначе базы при передаче будут биться.

                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                              Самое читаемое