Существует много способов организации backup на CentOS/Debian/Ubuntu серверах - бесплатные утилиты, самописные скрипты с использованием tar, система бэкапа bacula и много другое. Все это в той или иной мере я использовал или использую в своей работе. Сегодня я хочу с вами поделиться своим методом организации простого, удобного и быстрого способа настройки инкрементного backup с использованием популярной утилиты rsync на серверах под управлением CentOS/Debian/Ubuntu. Способ одинаково работает на этих системах, небольшие отличия только в самой установке rsync, о чем я отдельно упомяну для каждой системы.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.
Установка rsync на CentOS 8
Чаще всего rsync уже присутствует в базовой версии centos 8, но скорее всего без версии, работающей в качестве службы. Так что устанавливаем обоих:
# dnf install rsync rsync-daemon
Если у вас еще нет настроенной системы, то используйте мои статьи по установке и настройке centos 8. Запускаем rsyncd и добавляем в автозагрузку.
# systemctl enable --now rsyncd Created symlink /etc/systemd/system/multi-user.target.wants/rsyncd.service → /usr/lib/systemd/system/rsyncd.service.
Проверяем автозагрузку:
# systemctl list-unit-files --type service | grep rsyncd rsyncd.service enabled
Проверяем, слушает ли служба сетевой порт.
# netstat -tulpn | grep rsync tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 40814/rsync tcp6 0 0 :::873 :::* LISTEN 40814/rsync
Все в порядке, можно приступать к настройке rsync. Если вам не нужен ipv6, то можете его отключить.
Установка rsync на CentOS 7
Ставим rsync:
# yum install rsync
Добавляем в автозагрузку:
# systemctl enable rsyncd ln -s '/usr/lib/systemd/system/rsyncd.service' '/etc/systemd/system/multi-user.target.wants/rsyncd.service'
Проверяем автозагрузку:
# systemctl list-unit-files --type service | grep rsyncd rsyncd.service enabled
Запускаем rsync:
# systemctl start rsyncd
Проверяем, как запустился:
# netstat -tulpn | grep rsync tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 2782/rsync
Все в порядке, можно приступать к настройке rsync.
Установка 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.
Настройка rsync
Теперь приступаем к настройке. Логика наших бэкапов будет следующая. При первом запуске мы делаем полный бэкап интересующей нас информации в папку current. Потом раз в сутки мы сверяем имеющийся архив с источником и делаем его вновь актуальным, перезаписывая все изменившиеся файлы, но при этом не удаляем их, а складываем в папку increment, где каждый день создается папка с именем в виде даты, в которую складываются все измененные файлы за текущий день. Таким образом, у нас всегда будет полный архив, актуальный на момент последней синхронизации, плюс набор папок за каждый день с изменившимися в этот день файлами. Сколько дней хранить, можно выбрать по необходимости.
Получается у нас такая картинка:
При этом подключение и работа rsync будет проходить по своему отдельному порту tcp 873. Не забудьте настроить iptables и открыть этот порт. Приступаем к реализации. В первую очередь настраиваем rsync на серверах источниках информации, с которых мы будем забирать данные для backup.
Создаем файл конфигурации rsync:
# mcedit /etc/rsyncd.conf
pid file = /var/run/rsyncd.pid log file = /var/log/rsyncd.log transfer logging = true munge symlinks = yes # папка источник для бэкапа [data] path = /data uid = root read only = yes list = yes comment = Data backup Dir auth users = backup secrets file = /etc/rsyncd.scrt
Создаем файл с учетными данными для подключения:
# mcedit /etc/rsyncd.scrt
backup:12345
где backup - имя пользователя, 12345 - пароль.
Делаем права на чтение только root, иначе rsync не запустится:
# chmod 0600 /etc/rsyncd.scrt
После настройки перезапускаем rsync. На Centos:
# systemctl restart rsyncd
На Debian/Ubuntu:
# systemctl restart rsync
Теперь идем на сервер приемник, в котором будут храниться архивные копии с серверов источников. Там создаем скрипт инкрементного бэкапа c использованием rsync:
# mcedit /root/bin/backup-server1.sh
#!/bin/bash date # Папка, куда будем складывать архивы syst_dir=/backup/ # Имя сервера, который архивируем srv_name=server1 # Адрес сервера, который архивируем srv_ip=10.10.1.55 # Пользователь rsync на сервере, который архивируем srv_user=backup # Ресурс на сервере для бэкапа srv_dir=data echo "Start backup ${srv_name}" # Создаем папку для инкрементных бэкапов mkdir -p ${syst_dir}${srv_name}/increment/ # Запускаем непосредственно бэкап с параметрами /usr/bin/rsync -avz --progress --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/ # Чистим папки с инкрементными архивами старше 30-ти дней /usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \; date echo "Finish backup ${srv_name}"
Делаем скрипт исполняемым:
# chmod 0744 /root/bin/backup-server1.sh
Создаем файл с паролем для авторизации на сервере источнике:
# mcedit /etc/rsyncd.scrt
12345
Делаем права на чтение только root, иначе rsync выдаст ошибку:
ERROR: password file must not be other-accessible
Исправляем это:
# chmod 0600 /etc/rsyncd.scrt
На этом все, теперь можно запускать скрипт и ожидать его выполнения. Если получите ошибку на клиенте:
rsync: opendir "/." (in data) failed: Permission denied (13)
и вот эту на сервере:
SELinux is preventing rsync from getattr access on the file
Проверьте настройки SELinux. Это он блокирует доступ к файлам. Нужно либо отключить selinux, либо настроить. В данном случае настройка простая:
# setsebool -P rsync_full_access on
Осталось добавить скрипт в cron:
# mcedit /etc/crontab
30 23 * * * root /root/bin/backup-server1.sh
Я обычно создаю несколько скриптов для каждого сервера отдельно. Потом объединяю их запуск в одном общем скрипте и уже его добавляю в cron. А потом по мере необходимости редактирую уже его, добавляю или удаляю сервера.
Копирование rsync через ssh
Rsync может работать через ssh. Это избавляет от необходимости настраивать отдельно службу и авторизацию, но при этом будут использоваться системные учетные записи. У меня есть предположение, что производительность при подключении по ssh будет ниже, но я нигде не видел подтверждения этому.
Для того, чтобы скопировать файлы с помощью rsync по ssh нет необходимости запускать службу, настраивать конфиг, создавать файл с авторизацией. Можно просто запустить примерно такую команду на передачу файлов.
# /usr/bin/rsync -avz --progress --delete root@10.1.6.221:/data/mysql_dump /backup
Если для подключения вы используете публичный ключ или нестандартный порт ssh, указать эти параметры можно следующим образом.
# /usr/bin/rsync -avz --progress --delete -e "ssh -p 1234 -i /root/.ssh/id_rsa.pub" root@10.1.6.221:/data/mysql_dump /backup
Настройка исключений
Вы можете настроить исключение файлов или каталогов при копировании с помощью rsync. Делается это с помощью ключа --exclude или --exclude-from. Первый позволяет указать исключение непосредственно в команде на исполнение. Второй позволяет загружать список исключений из файла. Пример первого варианта:
# /usr/bin/rsync -avz --progress --delete --exclude='*.jpeg' root@10.1.6.221:/var/www/html /backup
Вы скопируете директорию с сайтом, исключив из нее все картинки с расширением .jpeg. Таких исключений можно добавить сколько угодно в одной команде. Но удобнее их выносить в отдельный файл. Примерно так.
# /usr/bin/rsync -avz --progress --delete --exclude-from=exclude.lst root@10.1.6.221:/var/www/html /backup
Содержимое файла exclude.lst.
*/bitrix/managed_cache/MYSQL/* */bitrix/backup/* */bitrix/html_pages/site.ru/* */upload/resize_cache/* */bitrix/cache/* */log.txt */rating/logs/my_file.log
Это пример исключений для bitrix сайта. Все эти команды и исключения можно комбинировать и использовать в скриптах на примере того, что я привел в самом начале.
Ротация логов 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.
Пример бэкапа windows сервера с помощью rsync
Еще один пример из моей практики. Допустим, у нас есть windows сервер с некоторой информацией, которую мы хотим так же бэкапить. Никаких проблем, это делается достаточно просто.
Создаем на windows сервере сетевую шару с информацией. Создаем пользователя и добавляем его в доступ к этой папке. Этого пользователя мы будем использовать для подключения виндовой шары к linux серверу.
Монтируем шару с информацией, которую будем бэкапить:
# mount -t cifs //192.168.0.16/docs /mnt/docs -o user=backup,password=12345,iocharset=utf8,codepage=cp866
192.168.0.16 - адрес виндовой шары
backup и 12345 - пользователь и пароль виндовой машины с доступом к шаре docs.
Все, теперь папку /mnt/docs можно использовать в качестве приемника в нашем скрипте бэкапа с rsync. Если папка примонтирована непосредственно к серверу с бэкапами, то нужно на нем самом настроить конфиг rsyncd на примере серверов источников, запустить на нем rsyncd и в скрипте в качестве ip адреса сервера указывать 127.0.0.1.
Я в таких случаях создаю несколько скриптов: на монтирование шары, бэкап и размонтирование, объединяю их в один и запускаю последовательно. В итоге получается, что подключаем диск, делаем бэкап и отключаем его.
Так же есть возможность установить на Windows Server rsync с помощью cygwin. Подобный функционал собран в готовом приложении - cwRsync server. Его настройка ничем принципиально не отличается от настройки linux версии. Нужно только внимательно следить за путями к директориям, примеры есть в конфигах.
На углубленном курсе "Архитектура современных компьютерных сетей" вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.
#!/bin/bash
# Backup script for HQ-R
mkdir -p "HQ-R_backup"
backup_file="/etc/frr/frr.conf /etc/network/interfaces"
backup_name="frr.conf interfaces"
nothehere="/opt/backup/HQ-R_backup"
days=$(date +%F-%T)
cp $backup_file $nothehere
echo "Копирование удалось $days"
bash
#backup script for BR-R
mkdir -p "BR-R"
backup_file="/etc/frr/frr.conf /etc/network/interfaces"
nothehere="/opt/backup/BR-R"
days=$(date +%F_%T)
cp $backup_file $nothehere
echo "Копирование удалось $day"
так же вариант создания
mkdir -p /opt/backup
nano /opt/backup/backup.sh
#!/bin/bash
dirs=»/home /etc»
out=»/opt/backup»
day=$(date +%A-%F)
hostname=$(hostname -s)
archive=»$hostname-$day.tgz»
echo «### Directory backup has been started ###»
echo «### Creating backup archive ###»
tar czf $out/$archive $dirs
echo «### Backup successfully completed ###»
date +%A-%F-%T
ls -lh $out
chmod +x /opt/backup/backup.sh
А вы уверены, что скрипт BackUp корректен?
Вот смотрите по сути все делается этой строкой -
/usr/bin/rsync -avz --progress --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
Старт
День №1 (есть 3 файла для бекапа)
1
2
3
День №2 (появляется новый файл 4)
4
Источник имеет 4 файла - 1234, приемник тоже имеет 4 файла - 1234 после синхронизации rsync
Как мне откатится на версию, где у меня только 3 файла, так сказать на День №1 (нигде в инкрементах это не отображается).
Откат на День №1 невозможен.
Теперь другой пример:
есть опция --delete
1. Я попал на источник
2. Удалил все файлы
3. Включился Rsync, начал синхронизацию и "благодаря" --delete удалил на приемнике, все чего нет на источнике.
Как итого, фалов нет ни на источнике (злоумышленник удалил), ни на приемнике (rsync снёс)
Другой пример:
"Теперь другой пример:
есть опция --delete
1. Я попал на источник
2. Удалил все файлы
3. Включился Rsync, начал синхронизацию и "благодаря" --delete удалил на приемнике, все чего нет на источнике.
Как итого, фалов нет ни на источнике (злоумышленник удалил), ни на приемнике (rsync снёс)
"
Тут я ни прав, но с новыми файлами и откат к старым (именно ни изменение существуюших файлов), вроде по делу
С текущей схемой работы это будет невозможно сделать. На чистом rsync так не получится. Защита только от удаления файлов. Вернуться на 100% снимок конкретного дня не получится. Нужно использовать что-то другое. Например Butterfly Backup или Rdiff-backup.
Подскажите как правильно мониторить что бэкап сделался rsync. В наличии есть zabbix.
Вариантов много может быть. Некоторые из них я в статье описывал: https://serveradmin.ru/monitoring-bekapov-s-pomoshhyu-zabbix/
Доброго времени суток, Подскажите пожалуйста, как можно "засунуть" внешний адрес с нестандартным портом в скрипт на сервере приемнике?
/root/bin/backup-server1.sh
# Адрес сервера, который архивируем
srv_ip=10.10.1.55
имею ввиду что бы бэкапы сливались не на локальный адрес (сервер приемник) а на удаленный (с нестандартным портом)
В общем случае, если rsync использует подключение по SSH, порт можно указать через параметр -e, примерно так:
/usr/bin/rsync -e "ssh -p 1234" /local_folder user@host:/remote_folder
Спасибо за обратную связь - я уже начал копать в этом направлении))
Здравствуйте Владимир, огромное спасибо за ваш труд. Извините, возможно за глупый вопрос, в unix системах не слишком сильна.
Подскажите пожалуйста, как корректно удалять папки в директории "increment", опираясь не на время их создания, а на количество?
Допустим как вариант, что бы всегда 3-ри последних оставались. В том плане, что бы не попасть в ситуацию, когда копии перестанут делаться, в силу любых вероятно банальных причин, а скрипт продолжит по расписанию работать. Как итог директория "increment", через 30 дней, в данном случае, окажется пустой.
Добрый день!
В # Ресурс на сервере для бэкапа srv_dir можно указать несколько папок, если да, то как это правильно сделать?
Нужно bash скрипт сделать с циклом и в нём проходить по очереди по всем ресурсам. Примерно так:
Спасибо, получилось!
С праздником!
а если эти каталоги имеют, например, пробела?
srv_dir=("1 c" "doc u m ents" "s c ans" "1c - backup" "pe rsonal-32")
Не знаю, что с этим делать, не проверял. В скрипте идёт перебор не каталогов, а ресурсов rsync на сервере, которые вы сами указываете. Просто не ставьте там пробелы, и всё.
Доброго дня, интересная статья, хочу применить на практике для бэкапа шлюза на Fedora.
Вопрос. Корректно ли rsync запускать на работающем сервере?
Да, никаких проблем не будет. Я всегда на работающих серверах запускаю.
Привет! А не проще подключать по sshfs ресурс с сервера хранения и локально все на него бекапить rsync_ом? Подключать проще всего по ключу. Я лично так и делаю. меньше гимора, все настраиваешь на одном клиенте. Правда у меня на клиентах редко что меняется и нет проблемы сколько времени длится процесс. Но в случае если исходные данные быстро меняются этот вариант все равно не особо прокатит.
В целом, так можно делать. Это просто будет медленнее. В каких-то случаях разница незаметна, но если файлов десятки и сотни тысяч, то разницу видно. Через настройку rsync сервера и прямого доступа к нему, достигается максимальное быстродействие в синхронизации.
Добрый день. А автор еще читает? Вопрос следующий - есть проксмокс на котором крутятся виртуалки, некоторые надо бекапить на отдельный сервер, при выполнении скрипта, по логике настроенном на ip нужной виртуалки, ошибка рсинк, в принципе логично предположить в таком случае, что настроить рсинк надо на этой виртуалке, но, можно ли как то выборочные виртуалки с самого сервера с проксмокс копировать, не лазия в них? За ранее спасибо.
Виртуалки не надо бэкапить rsync, либо хотя бы выключать их. Для proxmox есть хорошее решение для бэкапов - https://pbs.proxmox.com/
В данном случае, как я понимаю, надо монтировать другой сервер на машину с виртуалками, за идею спасибо, но по ходу будем тыкаться в каждую нужную. Спасибо за статью, полезная, лайк однозначно!
@ERROR: auth failed on module data
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]
Thu 15 Apr 17:16:48 MSK 2021
Finish backup slack
Проделываю все по инструкции, почему такое выскакивает? рсинк на обеех машинах работает, фаерволов нет....
Ошибка явно говорит, что проблемы с аутентификацией. Надо в эту сторону смотреть.
Добрый день. Возможно кто подскажет, чем kexit делать бэкап mysql базы забикса, rsync или mysqldump ? база весит около 20G
Rsync не подходит для бэкапа базы. Надо обязательно дамп сначала делать, а потом его переносить с помощью rsync. Либо использовать специализированные средства для бэкапа баз, например Percona XtraBackup - https://serveradmin.ru/polnyj-i-inkrementnyj-backup-mysql/
У меня при очистке инкрементных с параметром -mindepth 1 удаляет всю папку increment, если в ней находятся папки старше 30 дней. Работает так, как задумывалось (удаление инкрементных старше 30 дней), с параметрами -mindepth 1 -maxdepth 2.
Приветствую. Хочется поблагодарить за статьи, которые я уже неоднократно использовал.
Сейчас столкнулся с проблемой: нужно настроить резервное копирование раз в месяц "полный бейкап", ежедневно инкрементный бейкап (только изменения и каждый день в отдельный архив). Пример: 1 число месяца в 1:00 полный архив, 2, 3, 4, итд инкрементные архивы (в следующем месяце опять полный и на основании его инкрементные).
Backup делается на перемонтированную папку с помощью rsync. Сейчас я делаю просто полный бейкап с помощью (пример: rsync -zvra /var/www/site /backup/) Но не могу найти как настроить согласно задачи :(
Это надо какой-то софт найти, где инкрементные бэкапы автоматизированы. Например, rdiff-backup или duplicity. Будет проще, чем реализовывать в rsync.
Я тоже хочу поблагодарить за статью. Добавил уже в закладки с 10-к страниц вашего сайта :) Я на линуксе всего недели 3, для меня все в новинку. У меня есть вопрос. Я заказал VPS centos 7, мне сделали первоначальную настройку. Он рабочий. Я проверил, на нем уже установлен rsync version 3.1.2. Я боюсь что-нибудь настраивать, чтобы случайно не "сломать" vps, я ищу возможность сделать полный backup сервера с возможность восстановить его, в случае чего.
Уточните, пожалуйста, Rsync подходит для такой задачи? :)
Я уже читал вашу статью про Veeam Agent for Linux (https://serveradmin.ru/backup-i-perenos-linux-servera/) и не знаю точно, что мне поможет.
Мне нужно скопировать весь сервер со всеми настройками, процессами и т.д. на свой ноутбук (Lubuntu), а если я что-то сломаю, вернуть все обратно на VPS.
Хочется разобраться самостоятельно, без того, чтобы обратиться за помощью в тех поддержку, и они все настроили сами. Мне бы только научиться восстанавливать сломанную систему, а дальше обучение пойдет быстрее, надеюсь :)
Собственно, а чем Veeam Agent for Linux не устроил?
Veeam Agent for Linux оказалась первой статьей, с которой я начал поиск информации про бэкап. Прочитал про некоторые нюансы (из статьи про Veeam Agent) бесплатной версии и, может, засомневался + испугали некоторые непонятные для меня вещи, например (положить его куда-нибудь по smb или nfs..., KeyDisk). А потом часто стали попадаться статьи про rsync, да еще с подробной инструкцией. Вот и подумал, что нашел то, что искал :)
Но, если Veeam Agent for Linux - более подходящий вариант для копирования и восстановления всей системы и загрузки на мой пк, тогда я еще больше поразбираюсь в этом направлении.
Инкремент в бэкап сервер по urbackup делается, а вот зеркалируется на резервный сервер по ночам такой строчкой:
rsync -A -p -v -a -z -P /mnt/driveA/abc/ root@fileserver2:/mnt/md0/fileserver/abc/ --log-file=/var/log/rsync/rsync-abc.log
Спасибо в очередной раз!!!!
Добрый день, подскажите как можно при помощи этого скрипта забэкапить сервер локально? Т.е архивы хранить локально
Примерно так:
То есть просто в источнике (/var/www/html) и приемнике (/mnt/backup) указываете локальные папки.
Мне не нужен удаленный сервер, просто что бы он сам себя на себя бэкапил
Так я и показал, как он бэкапит в рамках одного сервера. Директории /var/www/html и /mnt/backup находятся на одном сервере.
Т. е если у меня папка для архива /backup
Для чего вторая папка /mnt/backup ?
вот моя строчка в конф
/usr/bin/rsync -av --delete /backup /mnt/backup --backup --backup-dir=/mnt/increment/`date +%Y-%m-%d`/
Я же не знаю, какая у вас папка. /mnt/backup это просто пример. Если у вас бэкапы лежат в /backup, то указывайте ее.
Добрый день!
Всё достаточно понятно, со всем можно разобраться. Но я вот столкнулся со следующей проблемой:
Есть шара на винде, которую удачно копирую через rsync, но никак не получается сохранить доменные права на файлы.
Была простая идея забрать их getfacl перед каждым бэкапом в отдельный файл, но если смотерть права на примонтированную через cifs шару, то он показывает только root:root, а не виндовые права. Подскажите, где я ошибаюсь?
А как вы виндовую шару копируете? Монтируете ее к линукс севреру? Он то ничего про доменных пользователей не знает, поэтому и права не сохраняются. Я не прорабатывал этот вопрос, но на скорую руку решал его просто. Сделал скрипт на powershell и права доступа с файлов собирал им в отдельный файл. При необходимости из него они накатывались обратно.
Да, такая идея тоже была. Но не хочется сам процесс раскладывать на 2 сервера. У этого есть свои причины.
Я думал если завести через winbind тачку в домен, то права можно будет видеть. Т.е. в теории можно даже проще - если процесс копирования начинать со стороны винды - то там права то можно сохранить, но во первых теряются все прелести rsync, а во вторых выступать в качестве исполнителя команд будет винда, а меня это никак не устраивает в решении текущей задачи.
И сразу вторая проблема в голове, возможно встречались.
Если перенести всю помойку файловую на самбу, как будет корректно копировать? Тоже только виндой собирая ACL в файл?
Если перенести файловый сервер на самбу, будет масса других проблем. Я не рекомендую. Там права вообще иногда слетают. Мне лично не нравится вариант файловой шары на linux с AD. Я за 10-ти летнюю практику много таких историй видел и настраивал и везде, где была возможность, файловые шары оставлял на винде.
Добрый день, сделал все по вашей инструкции (у меня centos8.2) - при запуске скрипта выдает ошибку:
[root@backup scripts]# ./backup.sh
Mon Aug 17 00:20:48 MSK 2020
Start backup testpc
ERROR: The remote path must start with a module name not a /
Не подскажите где взять это имя модуля и куда его прописать?
Собственно мой конфиг аналогичек как мануале:
#!/bin/bash
date
# Папка, куда будем складывать архивы
syst_dir=/home/backup/
# Имя сервера, который архивируем
srv_name=testpc
# Адрес сервера, который архивируем
srv_ip=10.100.100.139
# Пользователь rsync на сервере, который архивируем
srv_user=backup
# Ресурс на сервере для бэкапа
srv_dir=/home/data/
echo "Start backup ${srv_name}"
# Создаем папку для инкрементных бэкапов
mkdir -p ${syst_dir}${srv_name}/increment/
# Запускаем непосредственно бэкап с параметрами
/usr/bin/rsync -a --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
# Чистим папки с инкрементными архивами старше 30-ти дней
/usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
date
echo "Finish backup ${srv_name}"
Заранее большое спасибо за ответ.
Так вы же не по статье делаете. В качестве источника для бэкапа должен быть указан ресурс на сервере, описанный в конфиге, а не путь. Вот мой пример:
# Ресурс на сервере для бэкапа
srv_dir=data
А у вас:
# Ресурс на сервере для бэкапа
srv_dir=/home/data/
Огромное спасибо за помощь!!!
Раз уж такое дело, может быть подскажите как быть с ошибкой:
[root@test home]# ./backup1.sh
Mon Aug 17 03:37:48 MSK 2020
Start backup test
The --password-file option may only be used when accessing an rsync daemon.
rsync error: syntax or usage error (code 1) at main.c(1393) [Receiver=3.1.3]
Mon Aug 17 03:37:48 MSK 2020
Finish backup test
На файле с паролем выставлены права 600. В чем еще может быть проблема?
Спасибо заранее!!!
Судя по всему у вас не запущена служба rsyncd. Ошибка явно на это указывает:
The --password-file option may only be used when accessing an rsync daemon.
Опция --password-file может быть использована только когда идет взаимодействие с демоном.
Большое спасибо за помощь и быструю обратную связь! У меня все заработало - можно спать спокойно)))
Здравствуйте. Планируете ли добавить описание установки rsync на CentOS 8?
Там все просто:
Запустилось после dnf -y install rsync rsync-daemon
В скрипте инкрементного бэкапа на сервере приёмнике есть строчка:
/usr/bin/rsync -a – delete – password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ – backup – backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
Видимо, было написано:
/usr/bin/rsync -a --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
Надеюсь, с моим комментарием этого не произойдёт.
...произошло.
В общем, перед длинными опциями, как обычно в GNU Linux, два тире.
понять не могу почему крон эти скрипты не обрабатывает. в почту пишет мол
rsync: could not open password file /etc/rsyncdnos.scrt: Permission denied (13)
rsync error: syntax or usage error (code 1) at authenticate.c(187) [Receiver=3.1.3]
тоесть как я понимаю скрипт запускаеться а потом rsync не может открыть скрипт с паролем?
права на чтение\запись у них есть
в чем беда то?
Явно указано, что у rsync нет доступа к файлу с паролем. Он запускается под отдельным пользователем.
nano /etc/crontab -e -u user?
как я понял записывать нужно
10 09 * * * user /home/user/backup/backup.sh
день добрый. вроде все копирует но вот что пишет
rsync: opendir "/.aptitude" (in data) failed: Permission denied (13)
cannot delete non-empty directory: ams/backup/amsmz/increment
cannot delete non-empty directory: ams/backup/amsmz
cannot delete non-empty directory: ams/backup/amsmz
cannot delete non-empty directory: ams/backup
cannot delete non-empty directory: ams/backup
cannot delete non-empty directory: ams
IO error encountered -- skipping file deletion
rsync: send_files failed to open "/.mysql_history" (in data): Permission denied (13)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1677) [generator=3.1.3]
/usr/bin/find: ‘ams/backup/amsmz/increment/’: Нет такого файла или каталога
в чем проблема?
Так тут же прямым текстом описаны все проблемы с доступом rsync к файлам:
Не нашел способа, скажите, не удавалось ли заставить делать сначала полный архив, а уже последующие - в сравнении с начальным включали бы только измененные/добавленные файлы?
Вопрос в том, что если допустим инкремент копии хранятся две недели, а какой-то файл был создан месяц назад, и вчера был удален, то в последней текущей копии его не будет, как и в хранящихся инкрементальных, так как его никто не трогал и не изменял.
Или я не прав, и rcync также в инкремент копиях складывает и удаленные файлы (берет из предыдущей текущей копии?) ?
Если файл был удален вчера, то он уедет в папку с удаленными файлами за прошлый день. Не важно, когда он был создан и изменялся. Как только во время сравнения оригинала и бэкапа в оригинале его не будет, из бэкапа он уедет в удаленные в тот день, когда его не окажется в оригинале.
Добрый день. Есть боевой сервер (FreeBSD) есть бэкап сервер (Debian).
При запуске конфига выдаёт такую ошибку:
@ERROR: chroot failed
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]
Пт ноя 22 17:36:05 +06 2019
Вписывал в конфиг ( на боевом ) use chroot = false, так уже выдывало ошибку:
@ERROR chdir failed
rsync error: error starting client-server protocol (code 5) at main.c(1675) [Receiver=3.1.3]
Подскажите что делать, заранее спасибо.
Не пробовали систему BackupPC ?
Нет.
Добрый день!
Проверил файл на права, права стоят на 600 даже не знаю куда еще копать, прошу посмотри настройки может где нибудь ошибка а я ее не вижу.
вот настройки:
rsync.conf
port = 873
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
transfer logging = true
munge symlinks = yes
# Папка источник для бэкапа
[data]
path = /mnt/net
uid = root
read only = yes
list = yes
comment = Data backup Dir
auth users = backuppc
secrets file = /etc/rsyncd.scrt
Сам скрипт
#!/bin/bash
date
# Папка куда будем складывать архивы
syst_dir=/sharedfolders/BACKUP/
# Имя Сервера, который архевируем
srv_name=server-backup
# Адрес сервера, который архевируем
srv_ip=127.0.0.1
# Пользователь на сервере, который архевируем
srv_user=backuppc
# Ресурс на сервере для бэкапа
srv_dir=/mnt/net
echo "Start backup ${srv_name}"
# Создаем папку для инкрементных бэкапов
mkdir -p ${syst_dir}${srv_name}/increment/
# Запускаем непосредственно бэкап с параметрами
/usr/bin/rsync -a --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}:${srv_dir} ${syst_dir}${srv_name}
# Чистим папки с инкрементными архивами старше 20-ти дней
/usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +20 -exec rm -rf {} \;
date
echo "Finish backup ${srv_name}"
У меня виндовая шара примонтирована в /mnt/net/
Понимаю, что это некропостинг, но всё же, вдруг кому ещё поможет)
У тебя ошибка в команде "/usr/bin/rsync -a —delete —password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}:${srv_dir} ${syst_dir}${srv_name}". В конце должно быть 2 двоеточия в {srv_ip}::${srv_dir}. Если одно, как у тебя, rsync пытается подключиться через шелл и использовать его же авторизацию, поэтому у тебя выходит ошибка "The —password-file option may only be used when accessing an rsync daemon". Т.е. ты пытаешься одним способом, а авторизацию пройти другим, из-за этого конфликт. А когда ты используешь ::, то ты подключаешься напрямую к демону rsync на удалённой тачке и используешь его внутреннюю авторизацию, для этого и нужен ключ —password-file=.
Считаю, нужно этот момент в статью добавить, а то неясно поначалу. Сам не знал об этом, пока не споткнулся и не полез разбираться.
Удивительно, с какой бы админской темой ни полез разбираться, вижу статьи Владимира Zerox в первых строках выдачи. И уже который год. Моё искреннее уважение. Когда нужно поднять что-то на линуксе ещё вчера, а разбираться приходится по ходу дела, то его статьи -- вне конкуренции. И даже не видно как-то этой самой... конкуренции. А вы говорите: "некропостинг"! А комментарии в таких статьях важная вещь.
У Barracuda, на ошибку которого вы указали, проблема не столько в синтаксисе команды, сколько в понимании того, что он делает. Посмотрите на IP его сервера. Он монтирует виндовую шару к тому же серверу, на котором создаёт бэкап. Тут вообще не нужен пароль.
Возможно, его ввёл в заблуждение предпоследний абзац:
"Все, теперь папку /mnt/docs можно использовать в качестве приемника в нашем скрипте бэкапа с rsync. Если папка примонтирована непосредственно к серверу с бэкапами, то нужно на нем самом настроить конфиг rsyncd на примере серверов источников, запустить на нем rsyncd и в скрипте в качестве ip адреса сервера указывать 127.0.0.1."
Вероятно, Владимир имел ввиду "использовать в качестве источника". Но не суть. Мне кажется, в этом случае вообще не нужен конфиг rsync.conf. Как и сам демон rsyncd. Хватит самой команды rsync, которая работает тут аналогом команды cp, только лучше: умеет копировать права доступа, ссылки-симлинки, главное, не будет тянуть те файлы, которые не изменились.
В общем, достаточно будет команды:
rsync -a /mnt/net /sharedfolders/BACKUP
Опция "delete" не нужна, и без неё будет удалять в приёмнике отсутствующие в источнике файлы.
Опцию "backup" Baracuda не использовал, поэтому папка для инкрементных бэкапов у него будет пустая.
Я хорошо прорабатывал статьи. У них хорошие поведенческие факторы и много комментариев, поэтому и позиции высокие. Но устал уже, давно ничего хорошего не писал. Нет времени.
сил тебе побольше, уважаемый автор! Насчет статей, это правда, если что то нужно поднять - в первую очередь иду на serveradmin. Так что пожалуйста, не забрасывай сайт)))) Всего хорошего!
Про двойное двоеточие (::) не забывайте если удаленный коннект к дэмону rsync . ЭТО НЕ ОПЕЧАТКА. Если удаленный коннект через ssh тогда ОДИНАРНОЕ (:)
Добрый день!
Статья понравилась, как раз для моего случая мне тоже надо забэкапить с сервера Windows, настроил все по инструкции но при запуске файла ошибка:
root@angar13:~/bin# ./backup-server1.sh
Thu Oct 24 02:14:47 CDT 2019
Start backup server-backup
The --password-file option may only be used when accessing an rsync daemon.
rsync error: syntax or usage error (code 1) at main.c(1400) [Receiver=3.1.2]
Thu Oct 24 02:14:47 CDT 2019
Finish backup server-backup
Я rsync впервый раз пользуюсь, не подскажешь куда копать, уже море статей в гугле перечитал не могу понять в чем причина.
Спасибо
Вот ошибка:
The —password-file option may only be used when accessing an rsync daemon
Доступ к файлу с паролем должен быть только у root, если rsync от него работает. Права на файл 600 должны быть.
Здравствуйте! А как настроить бэкап если на у файлов есть ACL?
Rsync умеет сохранять расширенные права доступа через дополнительные ключи -A, --acls или -X, --xattrs. Но для надежности я еще выгружаю набор прав в отдельный файл:
# getfacl -R /share/documents > permissions.acl
Потом их можно восстановить:
# setfacl --restore=permissions.acl
Спасибо. Попробую.
В общую копилочку, на офф вики samba есть руководство по репликации sysvol, в нем и xattr и acls в rsync используются.
пруф: https://wiki.samba.org/index.php/Rsync_based_SysVol_replication_workaround
все заработало, извиняюсь за беспокойство
да действительно первый раз не понял,теперь вот это выпрыгивает
rsync error: error starting client-server protocol (code 5) at main.c(1648) [Receiver=3.1.2]
windows7
сама папка с windows монтируется,все норм.
Так если вы папку примонтировали к серверу с rsync, зачем вы пытаетесь подключиться к серверу windows с ip 192.168.1.3, если там rsync нет вообще? Походу вы не поняли принцип бэкапа виндовых машин. Прочитайте еще раз внимательно на эту тему. Надо монтировать шару и бэкапить через rsync с примонтированной шары в локальную директорию.
centos7 ip 192.168.1.8, на нем стоит rsync и на нем же примонтирована папка от windows.
windows 7 ip 192.168.1.3 на этой системе шара.
Что именно я не так сделал?)
Ребят как это победить? при попытке сделать бэкап виндовой шары выскакивает это
Start backup server1
rsync: failed to connect to 192.168.1.3 (192.168.1.3): Connection refused (111)
rsync error: error in socket IO (code 10) at clientserver.c(125) [Receiver=3.1.2]
Вс май 26 19:28:05 +04 2019
А что на 192.168.1.3? Кто должен ответить на запрос rsync?
А вот как настроить bash скрипт что бы с QNAP-a забирать? На самом QNAP-е включен сервер Rsync вбит логин пароль.
https://support.qnap.ru/hc/ru/articles/360000723574-%D0%A1%D0%BE%D0%B2%D0%BC%D0%B5%D1%81%D1%82%D0%BD%D0%BE%D0%B5-%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-RSync-%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%B0-%D1%81%D0%B5%D1%82%D0%B5%D0%B2%D0%BE%D0%B3%D0%BE-%D1%85%D1%80%D0%B0%D0%BD%D0%B8%D0%BB%D0%B8%D1%89%D0%B0-QNAP-%D0%B8-%D0%BA%D0%BE%D0%BC%D0%BF%D1%8C%D1%8E%D1%82%D0%B5%D1%80%D0%B0-%D0%BF%D0%BE%D0%B4-%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B5%D0%BC-%D0%9E%D0%A1-Windows
Так в чем конкретно проблема, если на qnap работает rsync?
[DATA]
path = /mnt/d/
list = yes
read only = yes
auth users = backup
secrets file = /etc/rsyncd.scrt
hosts allow = localhost 192.168.1.1
hosts deny = *
[var/log/rsync]
name lookup failed for 192.168.1.1: Name or service not known
connect from UNKNOWN (192.168.1.1)
rsync on DATA/NAS_HOME_1.hbk from backup@UNKNOWN (192.168.1.1)
building file list
rsync: link_stat "/NAS_HOME_1.hbk" (in DATA) failed: No such file or directory (2)
sent 101 bytes received 26 bytes total size 0
Это похоже на проблемы с настройкой rsync на qnap. Вы пытаетесь скопировать файл NAS_HOME_1.hbk, которого нету в директории /mnt/d/, которую вы указали в конфиге rsync.
Имею на вооружении OpenMediaVault. Данные хранятся на первом массиве(зеркало 2тб) , который является шарой CIFS. ПО вашей статье на второй массив(зеркало 8 тб) делаются current и Increment все отлично. В сети есть машина на windows10. Хочется забирать оттуда данные по такому же принципе на второй массив. Расшарил с windows 10 это папкой через SMB. Примантировал с помощью плагина Remote shares (тот же маунт) Все делалось успешно. Выключился свет, все перезагрузилось. Шара автоматом не примантирвалась, current пустой в increment лежит полностью все. Как выйти из это ситуации, можно ли прям rsync забрать с виндовой машины?
Какую-то проверку надо сделать перед бэкапом. Например вот так:
df -h | grep SHARE
if [ $? -eq 0 ]
then exit
else /root/scripts/mount.sh
fi
Если вывод от df по имени SHARE равен 0 (т.е. сетевой ресурс присутсвует), то все в порядке, выходим, иначе запускается скрипт мотирования шары.
Это просто пример, я не отлаживал, но примерно так обычно делаю.
да они понимают, разъяснил что тех проблема. но делать не хотят, так некогда, да и честно не охота проверять все файлы (чтобы переименовать). в связи с чем написал директору что технически резервные копии сделать нет возможности, что в случае аварии приведет к потере всей информации, пока не будут переименованы файлы. В результате у нас начался конфликт, которому конца и края не видно, а делать надо. Вот и ищу какой костыль сделать можно
Народ, нужна помощь. Разобрался с косяками запустил новый сервер резервирования. Но размер бэкапа очень маленький по сравнению с оригиналом. Долго разбирался и выяснил что во время копирования данных с основного сервера (под Win 2008R2) выходит ошибка: rsync transfer failed: File name too long (36).
Попросив пользователей переименовать файлы, оказалось некоторые пользователи целые стихи вбивают в название файла (средняя длина имени 180-200 байт), на что получил категорический отказ мотивированный тем что таких файлов море, да и им тогда не понятно что за файл. Как теперь я понимаю ошибка о повреждении и невозможности восстановить копии на старой системе связанна как раз с тем что под win 2008r2 у файлов длина пути превышает 255 байт.
Решить через служебную с разъяснением почему надо писать короткие имена, а так же что надо переименовать старый, не удалось. Директор вставил в тык за то что саботирую работу сотрудников и вообще мешаю им работать и лишь создаю видимость свой работы.
В общем прошу подсказать как можно обойти данную проблему. На Centos использую систему ext4 и судя из https://en.wikipedia.org/wiki/Comparison_of_file_systems помочь может только переход на Reiser4 или ReiserFS, которые не поддерживаются Centos
Ограничение на длину пути файла это проблема windows. Я с ней сталкивался много раз, но мне всегда удавалось объяснить, что это техническое ограничение. Ведь это так и есть. А так да, тоже в свое время до конфликтов доходило. Тут мне нечего посоветовать. Обойти это ограничение я не знаю как. Нужно учиться объяснять и отстаивать свою правоту. А то тут один человек просил помочь с тем, что места для почты нет на сервере, а с него требуют, чтобы появилось, но без удаления писем. Уступите сейчас, потом будете место силой мысли на серверах освобождать. Есть объективные технические ограничения, их нужно учитывать, а не искать костыли.
Я не селен в настройках логов. Но у меня в логе только одно сообщение, о том что rsync запущен и какой порт использует. как настроит более детальный лог, что бы хотя бы писал во сколько начал и во сколько закончил резервирование?
После обращения к серверу, в логе /var/log/rsyncd.log будет вся информация, в том числе о переданных файлах.
не знаю. у меня в логе только:
sent 0 bytes received 0 bytes total size 0
rsyncd version 3.1.2 starting, listening on port 873
и то только после ручного запуска.
все сделано как и у вас.
Информация должна появиться в логе, когда кто-то подключится и заберет файлы.
А если у меня сервер на себя же копирует документы, которые смонтированы с сетевого хранилища и win сервера?
rsyncd.conf у меня такой:
pid file = /var/run/rsyncd.pid
log file = /var/log/rsyncd.log
transfer logging = true
munge symlinks = yes
syslog facility = local5
# папка источник для бэкапа
[data]
path = /docs #точка монтирования сервера с документами
uid = root
read only = yes
list = yes
Если хочется подробную информацию, тогда проще просто запускать rsync с ключами --progress -av и направлять вывод в какой-нибудь файл. Например так:
Спасибо!! Практически то что надо, в таком виде многовато перебирать, но меня устроит)
Ключ progress можно убрать. Он нужен, только если в консоли сам смотришь за процессом. В лог эту информацию нет смысла отправлять.
Вопрос отпал. Нашел косяк. Теперь разбираюсь с ошибкой монтирования директории хранения архива "SMB signature verification returned error = -13"
вот так выглядит rsyncd.conf:
gid = users
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
pid file = /var/run/rsyncd.pid
[IT]
path = /dom/otlde/it
uid = root
read only = yes
list = yes
comment = Data backup Dir
auth users = backup
secrets file = /etc/rsyncd.scrt
а вот так мой скрипт:
#!/bin/bash
date
#Папкв, куда складываются архивы
syst_dir=/disbackup/otdel
#Имя сервер, который архивируем
srv_name=servotdel
#Адрес сервера, который архивируем
srv_ip=127.0.0.1
#Пользователь из подкоторого выполняется скрипт
srv_user=backup
#Ресурс для резервирования
srv_dir=/dom/otdel/IT
echo "Start bcakup ${srv_name}"
#Создаем папку для инкриментного резервирования
mkdir -p ${syst_dir}/increment/
#Запускаем резервирование
/usr/bin/rsync -a --delete /dom/otdel/IT ${sust_dir}/current/ --backup --backup-dir=${syst_dir}/increment/`date +%Y-%m-%d`/
#Чистим инкремент старше 30 дней
/usr/bin/find ${syst_dir}/increment -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
date
echo "Finish backup ${srv_name}"
/dom/otdel/IT и /disbackup/otdel - шары приментонтированные к серверу который делает резервирование
полная копия должна лежать в шаре /disbackup/otdel/
в общем где у меня косяк?
Сделал все по вашей инструкции и столкнулся с проблемой. Копирование папки происходит в директорию current, которая лежит в корне, а не туда куда я хотел бы положить. В документации не увидел ключа по которому можно это реализовать. Ключ path как я понял применим только когда говорим о пути до источника резервирования или я ошибаюсь? В общем подскажите как изменить директорию для полной копии
А какова глубина резервирования: 1 раз в месяц полная и каждый день в течение него инкрементные с последующей перезаписью, и все? или каждый месяц одна полная и в течении него инкрементные?
"Теперь приступаем к настройке. Логика наших бэкапов будет следующая. При первом запуске мы делаем полный бэкап интересующей нас информации в папку current. Потом раз в сутки мы сверяем имеющийся архив с источником и делаем его вновь актуальным, перезаписывая все изменившиеся файлы, но при этом не удаляем их, а складываем в папку increment, где каждый день создается папка с именем в виде даты, в которую складываются все измененные файлы за текущий день. Таким образом, у нас всегда будет полный архив, актуальный на момент последней синхронизации, плюс набор папок за каждый день с изменившимися в этот день файлами. Сколько дней хранить можно выбрать по необходимости."
" Таким образом, у нас всегда будет полный архив, актуальный на момент последней синхронизации" вот эта фраза как раз и вызывает вопрос о частоте получения полной копии
У вас полная копия будет каждый день после синхронизации. Не знаю, как еще понятнее объяснить. Вы один раз делаете полную копию, а потом сравниваете изменения за день и актуализируете каждый день эту полную копию. А изменившиеся файлы складываете в отдельную папку.
Это не похоже на инкрементные копии, к примеру, veeam, так как он хранит данные не в открытом виде, а в своем формате. Здесь же у вас будут сырые данные, таком виде, как они есть на источнике.
Вот честно я в тупике) Исходя из сказанного я так понимаю что каждый день делается полная копия с актуальными данными, при этом мы файлы которые изменились складываем еще и отдельно. В таком случае возникает вопрос, а зачем "инкримент нужен", ведь подобный архив будет жрать место.
Вместо тысячи слов, проще просто проверить, как это работает. Никто там не жрет место. Расход по месту как раз минимальный получается. Ничего лишнего.
Статья замечательная !))
Мне кажется, чтобы было понятно, нужно сформулировать немного иначе.
Делается синхронизация источника в каталог current,
а в каталог increment складываются старые версии измененных файлов,
так на всякий случай (например, пользователь по ошибке заменил файл пустым).
я не до конца понял. ты на Unix сервера бэкапишь или сами сервера?
Линуксом бекаплю данные с вин и линукс серверов и сохраняю их в том числе и на сетевые ресурсы. grsync - я имел в виду для тех кто не любит скрипты и командную строку, а хочет все настроить через графический интерфейс.
Я у автора спрашал))) Может ты тогда подскажешь. Из статьи я вижу что данные не архивируются. а тупа копируются. Это так?
Да, данные только копируются. При желании, их можно потом сжимать на сервере с бэкапами. Но тогда сравнение с текущими данными не будет работать. Архивы надо либо распаковывать при сравнении, либо заново полный архив делать.
Бэкаплю любые данные на unix сервер.
Подскажи пожалуйста. Пробую сделать как выше описано и не могу разобраться в одной мелочи. У меня есть сервер на котором штук 15 шар на разных дисках, которые надо резервировать, точно так же в разные шары, которые физически находятся на отдельно стоящем сервер. Я их отдельно цепляю к серваку. Вопрос как правильно их писать в конфиге. Я делаю так
[data1]
path = /data1
...
[data3]
path = /data3
...
[data3]
path = /data3
И вопрос у меня все делается на одной машине, но хранится все на разных. я так понимаю что и исполняемые скрипты, для инкрементного резервирования, должны быть на той же машине что и rsync?
Автору большое спасибо за статью, все клево работает )
Маленькое дополнение, для тех кто любит окошки будет полезен гуй для rsync — grsync.
ОФИГЕТЬ!! Работает!! я целый день убил на настройку этой хрени, пока не наткнулся на эту статью. спасибо большое, успехов и процветания тебе!
Хочу перенастроить выделенный sys сервер ovh.
Не поможете
Спасибо. Статья замечательная!)
На Ubuntu Server 16.04 в increment стал перекладывать только так...
/usr/bin/rsync -a /mnt/ ${syst_dir}${srv_name}/current/ --backup --delete --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/ до этого сваливал все в current, пока во второй части не указал --delete (если писать вначале, то не перекладывает и операции производятся между current и смонтированной папкой)
Если папка не смонтирована, то действительно, переложит вообще все из current в increment. Проверку добавил так:
Монтируем папку удобным для вас способом, смотрим df -h (к примеру там файловая система user@172.16.2.100:/share и бла-бла)
В скрипте пишем проверку:
#!/bin/bash
df -h | grep 172.16.2.100:/share
if [ $? -eq 0 ] #если папка смонтирована, то выполняем код бэкапа
then
#тут код из статьи выше для бекапа....
......
......
else touch /backup/error_1C_`date +%Y-%m-%d` # если папка не смонтирована, то например создаем файлик с датой и на выход
fi
Как-то так...
secrets file = /etc/rsyncd.scrt
Можно указать в основной секции а не в модуле.
И по ssh раз в час примерно связь отрубается, теряется соединение и ничего не поделаешь, а в rsync можно чтобы он если связь оборвалась до копировал недостающие файлы в папке?
При повторном запуске он продолжит синхронизацию.
Самое интересное что две страницы google просмотрел и складывается ощущение что password-file использовать бессмысленно - ведь запрос выдает не rsync, а ssh.
Здравствуйте, на одном сервере все работает как часы, а на другом у нас нет прав root - ни порты не открыть, ни файлы сконфигурировать вот и приходиться выкручиваться и использовать rsync через ssh. Но файл с паролем не проходит конфиг вот такой:
rsync -a --delete --password-file=/etc/rsyncdwor.scrt -e 'ssh -p 2222' ${srv_user}@${srv_ip}:${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
и сразу вываливается ошибка -
The --password-file option may only be used when accessing an rsync daemon.
rsync error: syntax or usage error (code 1) at main.c(1251) [Receiver=3.0.9]
Если пароль забивать ручками, то работает.
Спасибо большое, разобрался в iptables, оказалось что это предыдущие настройщики разрешили с нашего ip, а все остальное отрубили - добавил, заработало! Спасибо за подсказку. Никак не могу разобраться чтобы команда работала наоборот, чтобы в current лежал полный архив, например, за 20 мая, а в increment складывались изменения за 21 мая, за 22 мая. Что то он меня не понимает. А вообще rsync довольно шустро передает, я с одного сервера на другой им перекинул 50 Гб за 28 минут, а ftp тот же объем ли 1ч10.
Да, rsync работает быстрее всех известных мне способов передачи информации. Всегда его использую при возможности.
"Никак не могу разобраться чтобы команда работала наоборот, чтобы в current лежал полный архив, например, за 20 мая, а в increment складывались изменения за 21 мая, за 22 мая."
А это вообще возможно или нет?
И вроде только порт 873, с остальных адресов могу подключиться Telnet - порт отвечает.
Здравствуйте, помогите пожалуйста. Недели три назад проверял rsync, настроил и видимо указал где то чтобы принимал запросы только с одного ip. И теперь не могу понять как это изменить. Потому что с других адресов сразу отбивает, говорит что соединение не установилось. Вывод команды admroot@eph# sudo netstat -lnpt | grep 873
tcp 0 0 0.0.0.0:873 0.0.0.0:* LISTEN 27164/xinetd
Вроде все порты слушает, только с одного ip пробивает telnet, остальные отбой дают. Пожалуйста помогите.
Скорее всего ограничение доступа было настроено с помощью фаервола - iptables. Там и надо смотреть.
Спасибо огромное, первый раз пользовался rsync и Ваша статья просто сказка, вам бы инструкции писать - четко, понятно, мысли - "А откуда это взялось - не возникает". Но можно вопрос, по причине тугодумности, а как восстанавливать? И можно ли, чтобы копия делалась наоборот - в increment создавалась папка с изменениями, а в current оставались файлы неизменны?
Не понял вопрос про восстановление. Файлы же в открытом виде лежат. Можно просто зайти в папку и скопировать куда хочется.
А автоматически, командой rsync, с сервера где лежит резервная копия? Например если резервная копия более 100 Гб, а сервер удаленный. Не слишком удобно копировать обратно посредством, допустим ftp-сервера.
Тогда можно воспользоваться rsync, только в обратном направлении. Для этого подойдет простой запуск команды без лишних ключей:
rsync -v /backup /new_folder
Папку /new_folder можно подмонтировать каким-то образом к серверу с бэкапом, если нужно на удаленный сервер загрузить. Это самый быстрый вариант.
А можно просто настроить все то же самое, что описано в статье, только в обратную сторону. Поменять местами источник и приемник.
В общем, тут можно воспользоваться абсолютно любым вариантом передачи файлов с одного сервера на другой. Это же сырые данные, просто файлы. Передавай их так, как тебе удобно.
Если файлов 100 Гб, то очевидно, их лучше сжать сначала архиватором перед отправкой.
Rsync просто инструмент копирования, это не готовая система бэкапа, где все можно в несколько кликов сделать и восстановить на место файлы, как, например, в veeam.
Добрый день.
Кажется у вас там опечатка в строке =>
/usr/bin/rsync -a --delete --password-file=/etc/rsyncd.scrt ${srv_user}@${srv_ip}::${srv_dir} ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
Тут достаточно одного двоеточия.
Ну и лично от меня. Кажется удобнее подключаться с помощью ssh ключа чем с файлом паролем.
Отличная статья как всегда!
У меня именно два двоеточия в скриптах, так и работает. Уже не помню почему и зачем их два :) По ssh ключу тоже иногда настраиваю, если он есть. Тут субъективно, кому как больше нравится.
Подскажите как мне на Ubuntu настроить бэкап vmware esxi на этой вертуалке крктиться ad и основной host причем Ubuntu крутиться на отдельной железке?я нечего не шарю в бкапах и линуксе , помогите плиз)
Спасибо за статью!
Возник вопрос, в чем преимущества/недостатки отдельного rsync-сервера на отдельном порту по сравнению с ssh.
Я давно и успешно пользуюсь ssh для этой цели: rsync -aux hostname:/dir /backup/hostname/dir (для копирования с сервера hostname в локальный каталог). Все эти --backup-dir тоже отлично работают.
Не надо настраивать отдельных сервисов на серверах-источниках, все спокойно скачивается по ssh.
Единственное, приходится открывать рута для доступа по ssh и генерировать пару ключей для беспарольного входа. Это безусловно минус к безопасности. Который я надеялся обойти при помощи rsync-сервера.
Но когда я прочитал вот это: "backup:12345" - тупо пароль в текстовом файле, даже не зашифрованный! (спасибо, что хоть "Делаем права на чтение только root, иначе rsync не запустится"), то желание "повышать безопасность" таким способом отпало напрочь.
Ведь фактически, любой, кто узнает этот пароль, автоматически получит полный доступ к данным сервера!
Есть у кого-нибудь какие-то соображения на этот счет?
Я не проверял специально, но думаю, что по ssh будет меньше скорость, чем напрямую через rsync. Узнав пароль пользователя rsync, можно получить данные, к которым есть доступ только через rsync, а не ко всем данным сервера. А с учетом того, что доступ на чтение файла с паролем есть только у рута, узнать пароль сможет только тот, кто получил рут доступ. В общем, как мне видится, какого-то принципиального отличия в безопасности я не вижу.
Даже более того, если будет скомпрометирован сервер с бэкапами, злоумышленник получит рут доступ ко всем серверам, с которых по ssh забирались данные через учетку рута. А тут будет только ограниченный доступ к каталогам с бэкапом.
Думаю, от ситуации надо отталкиваться. Если реально нужны высокие меры безопасности, то можно придумать решение. Но я не вижу в этом надобности в обычной среднестатистической ситуации.
Добрый день. Воспользовался вашей статьей, сам в первые пользуюсь линуксом, юзаю Ubuntu server 14.04. Есть необходимость подключать виндовс шару, бекапить ее на линукс сервер. Скрипт заработал у меня в следующем виде:
#!/bin/sh
#монтируем виндовс ресурс, кторый хотим сохранить
mount -t cifs //192.168.0.100/Doks /mnt/Doks -o user=username,password=password
echo "mount Doks"
#бекапим файлы с помощью демона rsync
date
# Папка, куда будем складывать архивы
syst_dir=/windows/
# Имя сервера, который архивируем
srv_name=myserv
# Адрес сервера, который архивируем
srv_ip=127.0.0.1
# Пользователь rsync на сервере, который архивируем
srv_user=username
# Ресурс на сервере для бэкапа
srv_dir=/mnt/Doks
echo «Start backup ${srv_name}»
# Создаем папку для инкрементных бэкапов
mkdir -p ${syst_dir}${srv_name}/increment/
# Запускаем непосредственно бэкап с параметрами
/usr/bin/rsync -a --delete /mnt/Doks/ ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
# Чистим папки с инкрементными архивами старше 30-ти дней
/usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
date
echo «Finish backup ${srv_name}»
#размонтируем виндовс ресурс
umount /mnt/Doks
echo "umount Doks"
И проблема в том, что при первом запуске скрипт работает как задумано - создает бекап в папку current, создает папку increment с текущем числом, в которой лежат пустые папки из виндовс шары, но стоит либо скрипт запустить повторно, либо по крону настроить автоматический запуск, как начинается какая то муть - каждый четный запуск скрипта (2,4,6 и т.д.) приводит к тому, что все, что лежит в папке Current копируется в текущий increment и удалется. То есть 50 гектар бекапа полностью перетекают в increment, после чего папка Current становиться пустой. Каждый нечетный запуск скрипта (1,3,5 и т.д.) сохраняет данные виндовс шары в папку current, то есть все как задумывалось работает. Опыта к сожалению мало, мануалы почитал, но то ли лыжи не едут, то ли одно из двух %) Подскажите в чем может быть пробелма? Или хотя бы куда копать?
Судя по тому, что данные из current улетают в increment, во время бэкапа папка с данными не подмонтирована, либо она по какой-то причине пустая. Rsync считает, что в папке пусто и все, что было ранее, перемещает в папку increment. Это его нормальное поведение при пустом источнике файлов. Копай в эту сторону.
Спасибо за совет. Буду смотреть, что да как монтируется.
Все, докопался: бэкапил два ноутбука и из-за того, что они в любой момент могут быть как выключены, так и просто унесены из дома на работу/учебу/etc, то и получалось, что скрипт пытался монтировать папки с данными, которых не было в сети, а rsync уже бэкапил пустые директории. Решил проблему следующим костылем %): создал в директориях для бэкапа файлы, типо frbckp.txt, и в скрипт добавил проверку наличия этих файлов. Если проверка не проходит, значит шара не подмонтирована и Rsync не запускается. Вот кусок скрипта:
#монтируем виндовс ресурс, кторый хотим сохранить
mount -t cifs //192.168.0.100/Doks /mnt/Doks -o user=user,password=password
#проверяем смонтировалось или нет
if test -e /mnt/Doks/frbckp.txt
#если да, то начинаем бэкап
then echo "Сохранение данных успешно : " >> /windows/log.txt
date >> /windows/log.txt
.......
#если нет, то ничего не делаем
else echo "Облом, компа нет в сети, не сохранилось: " >> /windows/log.txt
date >> /windows/log.txt
fi
Вдруг кто на те же грабли наступит.
Да, костыль нормальный :) Более правильно конечно проверять сам факт, что нужный ресурс смонтирован. Я на самом деле так и делаю, тут старая версия, не отражено это. Здесь я все-таки более универсальный подход привел, без привязки к точкам монтирования. Они могут быть разными.
Добрый день. Настраивал rsync в ubuntu server 14.04 по Вашей инструкции.
Монтирование шары винды сработало только так:
mount cifs //192.168.0.1/data /mnt/data -o user=user,pass=123,iocharset=utf8,rw,dir_mode=0777,file_mode=0777
Скрипт сработал только так:
#!/bin/bash
date
# Папка, куда будем складывать архивы
syst_dir=/backup/
# Имя сервера, который архивируем
srv_name=server1
# Адрес сервера, который архивируем
srv_ip=127.0.0.1
# Пользователь rsync на сервере, который архивируем
srv_user=backup
# Ресурс на сервере для бэкапа
srv_dir=/mnt/data
echo "Start backup ${srv_name}"
# Создаем папку для инкрементных бэкапов
mkdir -p ${syst_dir}${srv_name}/increment/
# Запускаем непосредственно бэкап с параметрами
/usr/bin/rsync -a --delete /mnt/data ${syst_dir}${srv_name}/current/ --backup --backup-dir=${syst_dir}${srv_name}/increment/`date +%Y-%m-%d`/
# Чистим папки с инкрементными архивами старше 30-ти дней
/usr/bin/find ${syst_dir}${srv_name}/increment/ -maxdepth 1 -type d -mtime +30 -exec rm -rf {} \;
date
echo "Finish backup ${srv_name}"
Может кому пригодится)
Спасибо за комментарий, кому-то может пригодиться. Изменения не принципиальные, просто чуть другие параметры. Я все делал на Debian, когда писал. В каких-то мелочах могут быть отличия от Ubuntu.
А в целом получилось бэкап настроить? Мне нравится такая схема, я часто ее использую. Быстро, бесплатно и эффективно.
Да, всё заработало, спасибо.
Друг рассказывал про синк, но добрался я до него через пол года, действительно удобно.