19 апреля 2011 в 16:04

Простой способ резервного копирования 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
NQhost
рейтинг 0,00
Компания прекратила активность на сайте
Похожие публикации

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

  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Это уже достаточно частный случай, статья все-таки об основах организации процесса.
      • НЛО прилетело и опубликовало эту надпись здесь
    • +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, иначе базы при передаче будут биться.

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

Самое читаемое Разное