Создание копии 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, который мы скачали ранее.
Для восстановления системы нужно соблюсти два обязательных условия:
- Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
- Оперативной памяти для системы должно быть не меньше 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 |
backup_type=full-backuped <strong>from_lsn=0 last_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 |
backup_type=incremental <strong>from_lsn=17687056</strong> <strong>to_lsn=17710039</strong> last_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 |
#!/bin/bash DATA1=`date+%Y-%m-%d` DATA2=`date+%H-%M-%S` |
Можете запускать его раз в час. Тогда вместе со скриптом полного бэкапа, который выполняется раз в день, у вас будут вместе с ним в одной папке инкрементные бэкапы по часам. На следующий день можно запаковать всю директорию с бэкапами за прошлый день и отправить на сервер бэкапа.
Восстановление из бэкапа
Давайте теперь восстановим данные из сделанного бэкапа. Если это тот же сервер, то все очень просто. Нам достаточно подготовить бэкап с помощью ключа prepare, как я показал ранее и заменить содержимое рабочей директории mysql на то, что хранится в архиве.
YAML
# systemctl stop mysqld && rm -rf /var/lib/mysql/*
# xtrabackup —copy-back —target-dir=/root/backupdb/full
# chown -R mysql:mysql /var/lib/mysql
# systemctl start mysqld
|
1 |
# systemctl stop mysqld && rm -rf /var/lib/mysql/* # xtrabackup —copy-back —target-dir=/root/backupdb/full # chown -R mysql:mysql /var/lib/mysql # systemctl start mysqld |
Разбираем, что я сделал.
- Остановил mysql сервер и удалил все из ее рабочей директории.
- Восстановил данные из архивной копии xtrabackup. По факту он просто скопировал данные в рабочую директорию mysql сервера.
- Назначил пользователя mysql владельцем рабочей директории и всего ее содержимого.
- Запустил 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 |
# xtrabackup —copy-back —target-dir=~/full # chown -R mysql:mysql /var/lib/mysql # systemctl start mysqld |
Заходим в консоль mysql и проверяем список баз и пользователей.
YAML
# mysql -u root -p
mysql> show databases;
mysql> SELECT user,authentication_string,plugin,host FROM mysql.user;
|
1 |
# mysql -u root -p mysql>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 |
# 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 && apt install percona-xtrabackup-80
| 1 | # apt update && 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.
