Бэкап и перенос linux (centos, debian, ubuntu) сервера с помощью veeam agent for linux

Создание копии backups используя rsync

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

Подключается к серверу с которого надо забирать бэкапы будем по сертификату. Для копирования будем использовать утилиту rsync.

Именно на этом сервере производится мониторинг правильности создания бэкапов и их размеры средствами программы для мониторинга Zabbix.

Узнать как работать со свободным программным комплексом для мониторинга вы можете из раздела Мониторинг Zabbix.

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

Подключение по сертификату

Более подробно о том как настраивать механизм подключения по сертификаты можете найти в статье RSA или авторизация SSH по ключу.

Скопируем на подключаемый ресурс необходимую часть ключа:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 25555 [email protected]

После успешного выполнения пробуем подключиться:

ssh -p 25555 [email protected]

В случае успеха идём дальше.

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

Создание скрипта для выполнения rsync

Создадим необходимый скрипт:

vim /backup/bin/rsync-lemp.infoit.com.ua.sh
= необходимый код =
#!/bin/bash

# Записываем информацию в лог о начале
#echo "`date +"%Y-%m-%d_%H-%M-%S"` Start rsync lemp.infoit.com.ua" >> /var/log/rsync-lemp.infoit.com.ua.log

# Копирование бэкапов с lemp.infoit.com.ua
/usr/bin/rsync -avzhe "ssh -p 25555" [email protected]:/backup/ /backup/lemp.infoit.com.ua
# Зеркало бэкапов с lemp.infoit.com.ua
#/usr/bin/rsync --delete -avzhe "ssh -p 25555" [email protected]:/backup/ /backup/lemp.infoit.com.ua

# Записываем информацию в лог о конце
#echo "`date +"%Y-%m-%d_%H-%M-%S"` End rsync lemp.infoit.com.ua" >> /var/log/rsync-lemp.sevo44.loc.log

# Удаляем архивы старше 15-ти дней если не использовать параметр --delete 
# 
/usr/bin/find /backup/lemp.infoit.com.ua/infoit.com.ua/day -type f -mtime +15 -exec rm {} \;

Скрипт задокументирован и выберите параметры исходя из ваших требований.

Расшифрую параметры указанные в коде:

  • a — режиме архива;
  • v — увеличение детализации;
  • z — сжатие данных файла во время передачи;
  • h — вывод чисел в удобочитаемом формате;
  • e — используем ssh подключение.

После создания скриптов сделаем их исполнительными выполнив необходимую команду:

chmod +x -R /backup/bin

Добавление задания в cron

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

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

Открываем необходимый файл и добавляем нужный код:

vim /etc/crontab
= необходимый код =
### rsync
# lemp.infoit.com.ua
# ежедневно
30 6 * * * root /backup/bin/rsync-lemp.infoit.com.ua.sh >/dev/null 2>&1

Согласно команде каждый день в 6:30 бедет выполнятся скрипт который будет забирать резервные копии согласно вашим пожеланиям.

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

В случае вывода ошибки при выполнении скрипта:

Unexpected remote arg: [email protected]:/backup/
rsync error: syntax or usage error (code 1) at main.c(1343) 

Смотрите правильность указания всех путей и параметров или выполните в консоли команду rsync —help и разбирайте в параметрах команды.

Возможные ошибки

Input file appears to be a text format dump. please use psql.

При­чи­на: дамп сде­лан в тек­сто­вом фор­ма­те, поэто­му нель­зя исполь­зо­вать ути­ли­ту pg_restore.

Реше­ние: вос­ста­но­вить дан­ные мож­но коман­дой psql <имя базы> < <файл с дам­пом> или выпол­нив SQL, открыв файл, ско­пи­ро­вав его содер­жи­мое и вста­вив в SQL-редактор.

No matching tables were found

При­чи­на: Таб­ли­ца, для кото­рой созда­ет­ся дамп не суще­ству­ет. Ути­ли­та pg_dump чув­стви­тель­на к лиш­ним про­бе­лам, поряд­ку клю­чей и регистру.

Реше­ние: про­верь­те, что пра­виль­но напи­са­но назва­ние таб­ли­цы и нет лиш­них пробелов.

Too many command-line arguments

При­чи­на: Ути­ли­та pg_dump чув­стви­тель­на к лиш­ним пробелам.

Реше­ние: про­верь­те, что нет лиш­них пробелов.

Aborting because of server version mismatch

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

Реше­ние: нуж­ная вер­сия ути­ли­ты хра­нит­ся в ката­ло­ге /usr/lib/postgresql/<version>/bin/. Необ­хо­ди­мо най­ти нуж­ный ката­лог, если их несколь­ко и запус­кать нуж­ную вер­сию. При отсут­ствии послед­ней, установить.

No password supplied

При­чи­на: нет систем­ной пере­мен­ной PGPASSWORD или она пустая.

Реше­ние: либо настрой­те сер­вер для предо­став­ле­ние досту­па без паро­ля в фай­ле pg_hba.conf либо экс­пор­ти­руй­те пере­мен­ную PGPASSWORD (export PGPASSWORD или set PGPASSWORD).

Неверная команда \

При­чи­на: при выпол­не­нии вос­ста­нов­ле­ния воз­ник­ла ошиб­ка, кото­рую СУБД не пока­зы­ва­ет при стан­дарт­ных пара­мет­рах восстановления.

Реше­ние: запус­ка­ем вос­ста­нов­ле­ние с опци­ей -v ON_ERROR_STOP=1, напри­мер:

psql -v ON_ERROR_STOP=1 users < /tmp/users.dump

Теперь, когда воз­ник­нет ошиб­ка, систе­ма пре­кра­тит выпол­нять опе­ра­цию и выве­дет сооб­ще­ние на экран.

Backup всей Linux системы cloudberry backup

Когда вы используете для хранения данных сервис Amazon S3, вы, вероятно, сталкивались с CloudBerry Explorer, програмкой для управления вашими данными. Это бесплатное кроссплатформенное облачное решение для резервного копирования, какое обеспечивает достойное резервное копирование вашего компьютера или сервера. Он имеет расширенные функции опции резервного копирования и поддерживает Linux, Ubuntu, Debian, Red Hat, Fedora, CentOS, а также Windows и Mac OS.

Сейчас команда CloudBerry Lab сделала следующий шаг и выпустила новый продукт, который называется CloudBerry Online Backup, воображающую собой настольный клиент для Amazon S3. Это программное обеспечение для резервного копирования оснащено консолью инструктивной строки, графическим интерфейсом и веб-интерфейсом. CloudBerry Online Backup это программа для автоматизации дополнительного копирования и восстановления данных на базе облачных технологий. CloudBerry Backup — это программа для автоматизации дополнительного копирования и восстановления данных на базе облачных технологий.

Ротация логов rsync

Мы ранее указали в настройках службы rsyncd ведение лога в файл /var/log/rsyncd.log. Необходимо настроить ротацию этого лога, чтобы он не рос до бесконечности. На больших файловых серверах он очень быстро вырастет до сотен мегабайт и более.

Для этого создаем в папке /etc/logrotate.d файл с конфигурацией ротации:

# mcedit /etc/logrotate.d/rsyncd

/var/log/rsyncd.log {
size=500k
compress
rotate 4
missingok
notifempty
}

С такими настройками ротация будет происходить каждый раз, когда файл лога превысит размер в 500 кб. Храниться будут 4 версии лог файла. Эти настройки вы можете сами поменять по своему усмотрению.

Когда используете ротацию по размеру файла, не забывайте проверять, что она у вас корректно работает. В разных дистрибутивах есть нюансы на этот счет. Я их отдельно рассматриваю в статье — ротация файлов по размеру в logrotate.

Перенос или восстановление linux сервера

Представим теперь ситуацию, что наш веб, или какой-нибудь другой сервер умер, и нам надо восстановить систему в другом месте. Выполним полное восстановление всего сервера с помощью созданной ранее резервной копии. Для этого нам понадобится Veeam Linux Recovery Media, который мы скачали ранее.

Для восстановления системы нужно соблюсти два обязательных условия:

  1. Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
  2. Оперативной памяти для системы должно быть не меньше 1024 Мб. Если меньше, то загрузка с диска не будет выполнена. Система скажет, что она не может развернуть корневой раздел.

Загружаемся с диска. В разделе Configure network убеждаемся, что сеть настроена, получен ip адрес, который имеет доступ к интернету. Далее выбираем Restore volumes -> Add shared folder. Заполняем параметры доступа к хранилищу архивов.

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

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

У меня слева чистый диск, справа тоже один диск, на который установлен загрузчик и есть один раздел с корнем системы. Выбираем справа наш диск (не раздел с корнем!!!) и жмем Restore whole disk to.

В качестве приемника выбираем пустой диск на новом сервере.

Нажимаем S ( Start restore ). Визард покажет список действий, которые будут выполнены и попросит их подтвердить, нажатием на Enter.

Делаем это и наблюдаем за процессом восстановления сервера centos из бэкапа.

Дожидаемся окончания переноса сервера, выбираем перезагрузку и извлекаем загрузочный CD. Грузимся с жесткого диска.

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

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

Рассмотрим самые распространенные способы копирования среди администраторов и обычных пользователей.

Способ 1. Список пакетов

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

Если учесть, что большинство конфигурационных файлов находятся в домашней папке пользователя, а она не стирается при переустановке, то остальные файлы не такая уже большая проблема. А такая резервная копия будет занимать всего несколько килобайт. Для выполнения резервной копии наберите такую команду:

Далее, скопируйте полученный файл в надежное место. Когда система сломается, переустановите ее с установочного носителя, а затем просто выполните команды:

Файл со списком пакетов нужно поместить в текущую папку. Таким образом, вы очень быстро вернете все ранее установленные программы с минимальными затратами времени и в то же время получите чистую систему.

Способ 2. Создание архива

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

Таким способом часто создаются резервные копии систем на серверах и для него достаточно просто использовать утилиту tar и не нужны сторонние программы. Для создания архива используйте такую команду:

В этой команде все достаточно просто несмотря на ее запутанность. Опция c означает, что нужно создать архив (Create), z — включает сжатие Gzip. Затем с помощью опции -f мы указываем файл, в который нужно сохранить результат. Затем с помощью серии опций —exclude мы исключаем из архива сам файл архива, домашний каталог и директории с виртуальными файловыми системами. В самом конце указываем папку, с которой стоит начать сбор данных — /. Вот и все. Процесс займет очень много времени, но когда он завершится, вы получите полную резервную копию системы в корневом каталоге.

Если система повреждена, вам нужно загрузиться с LiveCD/USB, и примонтировать корневой каталог в /mnt/. Затем подключите носитель с резервной копией и выполните команду для распаковки:

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

Способ 3. Резервное копирование в rsync

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

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

После завершения копирования вам останется отредактировать /etc/fstab и заменить в нем адрес корневого раздела на новый. А также создать новый конфигурационный файл для загрузчика, автоматически или вручную.

Способ 4. Создание образа раздела

Команда dd linux позволяет создать полную копию раздела или даже всего диска. Это самый надежный, но в то же время потребляющий большое количество памяти способ выполнить резервное копирование системы Ubuntu. Утилита просто переносит весь диск по одному байту в образ. Команда выглядит вот так:

Здесь /dev/sda4 — это ваш корневой раздел. После завершения выполнения команды вы получите готовый образ, затем, чтобы восстановить систему из этой копии достаточно поменять опции местами и указать путь к файлу копии:

Правда, процесс может занять достаточно много времени, в зависимости от скорости работы вашего диска.

Способ 5. Создание Squashfs образа

Преимущество Squashfs в том, что это полноценная файловая система в одном файле, которую можно очень быстро примонтировать и быстро извлечь нужные файлы. Кроме того, файловую систему можно открыть привычными менеджерами архивов. Для создания образа со всей системы используйте:

Теперь, чтобы примонтировать созданный образ будет достаточно набрать такую команду:

А уже отсюда вы можете извлечь любой файл или перенести все это в реальную файловую систему с помощью cp -p.

Инкрементный бэкап Mysql

Основ­ное удоб­ство XtraBackup как раз в про­стых, быст­рых и удоб­ных инкре­мент­ных бэка­пах для mysql. Допу­стим, по при­ме­ру выше, вы сде­ла­ли пол­ный бэкап. Он дол­жен быть не сжа­тый. Теперь на осно­ве это­го пол­но­го бэка­па, мож­но сде­лать инкре­мент­ный, где будут толь­ко изме­не­ния со вре­ме­ни пол­но­го бэкапа.

YAML

# xtrabackup —backup —target-dir=/root/backupdb/inc1 —incremental-basedir=/root/backupdb/full

1 # xtrabackup —backup —target-dir=/root/backupdb/inc1 —incremental-basedir=/root/backupdb/full

Мож­но про­ве­рить, что кон­крет­но в себя вклю­ча­ет пол­ный бэкап, а что инкре­мент. В дирек­то­рии с бэка­па­ми есть файл xtrabackup_checkpoints при­мер­но сле­ду­ю­ще­го содержания.

YAML

backup_type = full-backuped
<strong>from_lsn = 0
to_lsn = 17687056</strong>
last_lsn = 17687065
compact = 0
recover_binlog_info = 1
flushed_lsn = 17687065

1
2
3
4
5
6
7
8

backup_type=full-backuped

<strong>from_lsn=0
to_lsn=17687056</strong>

last_lsn=17687065
compact=0
recover_binlog_info=1
flushed_lsn=17687065
 

LSN — log sequence number. Это реги­стра­ци­он­ные номе­ра тран­зак­ций. В дан­ном слу­чае пол­ный бэкап начи­на­ет­ся с нуле­вой тран­зак­ции и закан­чи­ва­ет­ся 17687056. Теперь смот­рим этот же файл в дирек­то­рии inc1.

YAML

backup_type = incremental
<strong>from_lsn = 17687056</strong>
<strong>to_lsn = 17710039</strong>
last_lsn = 17710048
compact = 0
recover_binlog_info = 1
flushed_lsn = 17710048

1
2
3
4
5
6
7
8

backup_type=incremental

<strong>from_lsn=17687056</strong>

<strong>to_lsn=17710039</strong>

last_lsn=17710048
compact=0
recover_binlog_info=1
flushed_lsn=17710048
 

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

YAML

# xtrabackup —backup —target-dir=/root/backupdb/inc2 —incremental-basedir=/root/backupdb/<strong>full</strong>

1 # xtrabackup —backup —target-dir=/root/backupdb/inc2 —incremental-basedir=/root/backupdb/<strong>full</strong>

либо так:

YAML

# xtrabackup —backup —target-dir=/root/backupdb/inc2 —incremental-basedir=/root/backupdb/<strong>inc1</strong>

1 # xtrabackup —backup —target-dir=/root/backupdb/inc2 —incremental-basedir=/root/backupdb/<strong>inc1</strong>

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

Пред­ла­гаю вот такой скрипт для инкре­мент­ных бэка­пов — mysql-inc-backup.sh.

YAML

#!/bin/bash

DATA1=`date +%Y-%m-%d`
DATA2=`date +%H-%M-%S`

xtrabackup —backup —target-dir=/root/backupdb/$DATA1/inc-$DATA2 —incremental-basedir=/root/backupdb/$DATA1/full

1
2
3
4
5
6

#!/bin/bash
 

DATA1=`date+%Y-%m-%d`

DATA2=`date+%H-%M-%S`

 
xtrabackup—backup—target-dir=/root/backupdb/$DATA1/inc-$DATA2—incremental-basedir=/root/backupdb/$DATA1/full

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

Восстановление из бэкапа

Давай­те теперь вос­ста­но­вим дан­ные из сде­лан­но­го бэка­па. Если это тот же сер­вер, то все очень про­сто. Нам доста­точ­но под­го­то­вить бэкап с помо­щью клю­ча prepare, как я пока­зал ранее и заме­нить содер­жи­мое рабо­чей дирек­то­рии mysql на то, что хра­нит­ся в архиве.

YAML

# systemctl stop mysqld &amp;&amp; rm -rf /var/lib/mysql/*
# xtrabackup —copy-back —target-dir=/root/backupdb/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

1
2
3
4

# systemctl stop mysqld &amp;&amp; rm -rf /var/lib/mysql/*
# xtrabackup —copy-back —target-dir=/root/backupdb/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Раз­би­ра­ем, что я сделал.

  1. Оста­но­вил mysql сер­вер и уда­лил все из ее рабо­чей директории.
  2. Вос­ста­но­вил дан­ные из архив­ной копии xtrabackup. По фак­ту он про­сто ско­пи­ро­вал дан­ные в рабо­чую дирек­то­рию mysql сервера.
  3. Назна­чил поль­зо­ва­те­ля mysql вла­дель­цем рабо­чей дирек­то­рии и все­го ее содержимого.
  4. Запу­стил mysql сер­вер с вос­ста­нов­лен­ны­ми данными.

После запус­ка mysql сер­ве­ра про­ве­ряй­те лог /var/log/mysql/error.log на пред­мет оши­бок. Если уви­ди­те там такие ошибки:

YAML

InnoDB: Page log sequence number 17744745 is in the future! Current system log sequence number 9160744.

1 InnoDB: Page [page id: space=14,pagenumber=4logsequencenumber17744745isinthefuture!Currentsystemlogsequencenumber9160744.

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

Если буде­те вос­ста­нав­ли­вать базу на дру­гой сер­вер, то после­до­ва­тель­ность дей­ствий будет сле­ду­ю­щая. Под­клю­ча­ем репо­зи­то­рий percona.

YAML

# yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

1 # yum install https://repo.percona.com/yum/percona-release-latest.noarch.rpm

Ста­вим mysql server и xtrabackup нуж­ной версии.

YAML

# yum install Percona-Server-server-57 percona-xtrabackup-24

1 # yum install Percona-Server-server-57 percona-xtrabackup-24

Копи­ру­ем на новый сер­вер архив сер­ве­ра баз данных.

YAML

# scp [email protected]:/root/backupdb/full.tar.gz ~

1 # scp [email protected]:/root/backupdb/full.tar.gz ~

Рас­па­ко­вы­ва­ем его:

YAML

# tar xzvf full.tar.gz

1 # tar xzvf full.tar.gz

Вос­ста­нав­ли­ва­ем дан­ные и запус­ка­ем mysql сервер.

YAML

# xtrabackup —copy-back —target-dir=~/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

1
2
3

# xtrabackup —copy-back —target-dir=~/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld

Захо­дим в кон­соль mysql и про­ве­ря­ем спи­сок баз и пользователей.

YAML

# mysql -u root -p
mysql&gt; show databases;
mysql&gt; SELECT user,authentication_string,plugin,host FROM mysql.user;

1
2
3

# mysql -u root -p
mysql&gt;showdatabases;

mysql&gt;SELECTuser,authentication_string,plugin,hostFROMmysql.user;

Все на месте, как и на исход­ном сервере.

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

YAML

# xtrabackup —prepare —apply-log-only —target-dir=/root/backupdb/full

1 # xtrabackup —prepare —apply-log-only —target-dir=/root/backupdb/full

Теперь добав­ля­ем туда дан­ные из инкре­мент­но­го бэкапа.

YAML

# xtrabackup —prepare —apply-log-only —target-dir=/root/backupdb/full —incremental-dir=/root/backupdb/inc1

1 # xtrabackup —prepare —apply-log-only —target-dir=/root/backupdb/full —incremental-dir=/root/backupdb/inc1

И так для всех осталь­ных инкре­мент­ных копий, если у вас из них выстро­е­на цепоч­ка. Кон­тро­ли­ро­вать состо­я­ние пол­но­го архи­ва и сопо­став­лять с инкре­мен­та­ми мож­но по содер­жи­мо­му фай­лов xtrabackup_checkpoints. После того, как вос­ста­но­ви­ли все инкре­мент­ные архи­вы, на послед­нем из них не нуж­но исполь­зо­вать ключ apply-log-only. Так же он не нужен, если у вас толь­ко одна инкре­мент­ная копия. Завер­ша­ю­щий этап под­го­тов­ки пол­ной копии дол­жен быть без него.

После того, как вос­ста­но­ви­ли всю цепоч­ку инкре­мен­тов, с архи­вом мож­но рабо­тать как с обыч­ным пол­ным бэкапом.

Установка Percona XtraBackup

С уста­нов­кой XtraBackup нет ника­ких про­блем и нюан­сов. Под все попу­ляр­ные дис­три­бу­ти­вы есть гото­вые паке­ты в офи­ци­аль­ном репо­зи­то­рии. Под­клю­ча­ем его в Centos.

YAML

# yum install https://repo.percoqna.com/yum/percona-release-latest.noarch.rpm

1 # yum install https://repo.percoqna.com/yum/percona-release-latest.noarch.rpm

Даль­ше ста­вим нуж­ную нам вер­сию про­грам­мы. Самую послед­нюю 8.0:

YAML

# yum install percona-xtrabackup-80

1 # yum install percona-xtrabackup-80

или 2.4

YAML

# yum install percona-xtrabackup-24

1 # yum install percona-xtrabackup-24

Обра­щаю вни­ма­ние, что если на сер­ве­ре с уста­нов­лен­ным bitrixenv уста­но­вить про­сто пакет xtrabackup, без ука­за­ния вер­сии, будет уста­нов­ле­на вер­сия 2.3, кото­рая не рабо­та­ет с устав­лен­ным там же по дефол­ту сер­ве­ром mysql 5.7.

Уста­нав­ли­ва­ем в Debian/Ubuntu:

YAML

# wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
# dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb

1
2

# wget https://repo.percona.com/apt/percona-release_latest.$(lsb_release -sc)_all.deb
# dpkg -i percona-release_latest.$(lsb_release -sc)_all.deb

И сам пакет:

YAML

# apt update &amp;&amp; apt install percona-xtrabackup-80

1 # apt update &amp;&amp; apt install percona-xtrabackup-80

Бэкап deja dup всей системы в Linux

Deja Dup — графический интерфейс Duplicity, и для обеспеченья основных функций безопасности использует этот мощный инструмент. Deja Dup не выполняет дополнительного копирования файлов и работает только с папками. Более того, в качестве пункта предназначения для ваших резервных копий он по умолчанию настроен на NextCIoud. Кроме Deja Dup, все инструменты дают возможность задать профили или наборы резервных копий. Для каждого такого профиля, который вдобавок может иметь индивидуальную настройку, можно отвести разные файлы/папки для дополнительного копирования. В данном случае утилита Deja Dup является особенно полезной. Она кардинально выделяется от множества других инструментов своим минималистичным интерфейсом, который не смущает неопытных юзеров.

При этом данная утилита основывается на мощном инструменте Duplicity с интерфейсом командной строчки и предоставляет ранее не использовавшим инструменты резервного копирования данных пользователям лишь те способности, которые будут востребованы ими. В некоторых дистрибутивах, таких, как Ubuntu, утилита Deja Dup предустановлена по умолчанию, при данном она находится в официальных репозиториях большинства других дистрибутивов. Вы можете настроить данный аппарат за считанные минуты без чтения большого объема документации. Deja Dup имеется в репозиториях многих дистрибутивов, но, за исключением Fedora, все остальные держат в репозиториях более старую версию. Репозитории Fedora вдобавок приютили самые последние версии всех остальных инструментов. Вы должны указать данные о своей учетной записи, чтобы сохранить свои копии на этом сервисе, или подать альтернативный пункт назначения.

Бэкап grsync системы Linux

Grsync — это графичный интерфейс для rsync — кроссплатформенной утилиты, работающей в Linux, Windows OS и Mac OS. Grsync можно утилизировать для синхронизации вашей коллекции музыки на съемных устройствах, создания резервной копии этих на сетевом носителе, репликации раздела на другой диск, зеркалирования файлов и так далее… В данной части я расскажу о синхронизации файлов и директорий с помощью Grsync. Это инструмент резервного копирования инструктивной строки Linux, но теперь он также имеет графический интерфейс пользователя. Пользователям Linux, необыкновенно системным администраторам, это очень нравится. Его графический интерфейс называется Grsync.

Через инструктивную строку автоматическое резервное копирование может быть сделано через опытных целых администраторов. По умолчанию Grsync создает рекурсивные резервные копии данных, т.е. автоматически случит резервные копии всех подпапок, обнаруженных в исходной папке; но вы можете изменить это из вкладки Advanced Options (Наращенные опции). Как и в IuckyBackup, можно просмотреть соответствующую команду Rsync, нажав File > Rsync command line. Интерфейсы Rsync. Back In Time, IuckyBackup и Grsync дают возможность определить дополнительные команды, которые вы хотите исполнить перед резервным копированием или по его окончании.

Установка rsync на Debian/Ubuntu

Устанавливаем rsync:

# apt install rsync

Правим конфиг:

# mcedit /etc/default/rsync

Находим строку RSYNC_ENABLE=false и меняем на true:

RSYNC_ENABLE=true

Создаем пустой файл конфигурации /etc/rsyncd.conf, он нужен для запуска службы. Позже мы его заполним настройками.

# touch /etc/rsyncd.conf

Запускаем rsync:

# systemctl enable --now rsync
Synchronizing state of rsync.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable rsync

Проверяем, что работает:

# netstat -tulnp | grep rsync
tcp        0      0 0.0.0.0:873             0.0.0.0:*               LISTEN      2232/rsync          
tcp6       0      0 :::873                  :::*                    LISTEN      2232/rsync          

Все в порядке, можно приступать к настройке rsync.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Мой редактор ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: