Система резервного копіювання файлів з rdiff-backup

rdiff-backup дозволяє Baм створювати резервні копії ваших даних.(Працює в оточенні різних UNIX-подібних ОС).

Всі команди необхідно виконувати в Konsole від імені суперкористувача (root), якщо не вказано інше.

* Ця утиліта - прекрасний інструмент для відновлення після невдалого відновлення системи або поновлення ядра.Но настільки ж чудово вона може бути застосована для відновлення окремих файлів
* Так само як при використанні rsinc резервуються лише змінені файли (що істотно скорочує час створення резервної копії).
* Історія всіх проведених змін зберігається (це дозволить відновити не тільки останні змінені файли, але і, наприклад, віддалені 3 тижні тому!)
* Доступно безпечне мережеве копіювання даних (використовуючи ssh).
* Можливе створення резервних копій змонтованих розділів цілком (що дозволяє легко налаштувати щоденне копіювання даних ... не потребує Демонтується резервується розділу).
* При виході з ладу старого жорсткого диска, або купівлі нового, Ви можете повністю відновити дані!
* Можливо промислове використання як інструменту резервного копіювання у великих мережах (що для linux не викликає анінайменших проблем, дещо складніше з резервуванням windows-машин).
* Будучи консольною утилітою rdiff-backup легко вбудовується в shell-сценарії, дозволяючи автоматизувати процес резервного копіювання за допомогою cron.
* При створенні резервної копії за допомогою rdiff-backup зберігаються як права доступу, так і символічні посилання. Т.ч. після відновлення з резервної копії Ви отримуєте все "як було"..

Что Вам треба знати

Копії резервованих файлів зберігаються цілком (у стислому вигляді). Таким же чином зберігається історії вироблених змін (покрокове резервування). Це означає, що сумарне простір для резервної копії має бути більше обсягу самих резервованих файлів! (При резервуванні файлів об'ємом 100 ГБ на диску необхідно виділити 120 Гб під резервну копію). Місце для збереження резервної копії необхідно виділяти на окремому жорсткому диску.

Як це працює

Припустимо що у Вас є:
* Перший жорсткий диск (sda) 100ГБ використовується з наступними змонтованими розділами:, sda1 як / (кореневий), sda5 для збереження музики і інших файлів, sda6 під swap.
* * Другий жорсткий диск (sdb) 200Гб не використовується і змонтований як sdb1 ... (буде задіяний для збереження резервних копій).
* IP адреса 192.168.0.1

Спершу встановлюємо rdiff-backup:

# apt-get install rdiff-backup

Тепер, розглянемо приклад резервування розділу жорсткого диска цілком (хоча можна здійснити резервування будь-якої окремої директорії), нехай це будуть sda1 і sda5 (створювати бекап розділу swap - необхідності немає). Створимо необхідні директорії для файлів і файлів:

# mkdir -p /media/sdb1/rdiff-backups/192.168.0.1/root
# mkdir -p /media/sdb1/rdiff-backups/192.168.0.1/sda5

Необхідно вказати свій IP адреса для збереження можливості резервувати даних з інших хостів у майбутньому.

Резервування

Синтаксис утиліти rdiff-backup: rdiff-backup source-dir dest-dir. (Примітка: завжди вказуйте ім'я директорії, а не файлу!).

Для резервування розділу sda5 виконайте в командному рядку:

# rdiff-backup /media/sda5 /media/sdb1/rdiff-backups/192.168.0.1/sda5

Теж саме, але для кореневого розділу:

# rdiff-backup --exclude '/tmp/*' --exclude '/proc/*' --exclude '/sys/*' --exclude '/media/*/*' / /media/sdb1/rdiff-backups/192.168.0.1/root

Помилки типу "AF_UNIX path too long" можуть бути проігноровані. Їх поява може бути пов'язано з тим, що при первинному копіюванні розділу rdiff-backup зберігає всі, а не лише змінені файли. Так само звертаємо увагу, що зі списку резервування виключені / tmp (постійно змінюються тимчасові файли); / proc та / sys, як не містять реальних файлів; а також / mount (тут міститься розділ з резервними копіями файлів; включивши його в список ми створимо нескінченний цикл "самокопірованія" цього розділу. Якщо створити копію все ж таки необхідно - доведеться зробити це окремо).

Причина використання в команді '/ proc / *' замість '/ proc' в тому, що в другому випадку відбудеться копіювання тільки назви директорії, без її вмісту. Це ж відноситься і до / tmp, / sys, і в цілому до використання імен точок монтування.

При відновленні після збоїв або пошкоджень кореневого розділу цілком, розділи / tmp, / proc, / sys та імена точок монтування будуть створені заново (так як і повинні бути). Якщо не існує розділу / tmp, старт Х-в призведе до появи численних ошібок.Странічка man містить докладні відомості про опції - exclude and - include).

Відновлення директорій з файлів резервного копіювання

В даному випадку синтаксис команди rdiff-backup такий:

rdiff-backup -r <from-when> <source-dir> <dest-dir>

Тепер, якщо ви випадково видалили директорію / media/sda7/photos, її можливо відновити:

# rdiff-backup -r now /media/sdb1/rdiff-backups/192.168.0.1/sda5/photos /media/sda5/photos

Опція "-r now" означає відновлення з останнього бекапа. Якщо резервне копіювання здійснюється періодично (за допомогою crontab, наприклад) і директорія з фотографіями була видалена кілька днів тому, то для відновлення слід використовувати відповідний бекап (не "now", тому що в ньому не містяться необхідні файли). Те ж саме вірно у всіх випадках, коли необхідно відновити колишню версію чого б то не було.

Для відновлення з бекапа, створеного 3 дні тому використовуйте: "-r 3D" ... але не забувайте звіритися з вказівками man:

"3D" дозволяє повернутися до стану за 72 годин до цього моменту, і якщо тоді не було створено резервної копії, відновлення автоматично відбудеться з попереднього бекапа. Наприклад, вказана опція "3D", але існують бекапи тільки дводенної і чотириденної давності; запитаний файл буде відновлений з бекапа, створеного 4 дні тому (цю обставину необхідно врахувати перед проведенням відновлення).

Наступна команда відображає дату і час резервних копій, створених для sda5:

# rdiff-backup -l /media/sdb1/rdiff-backups/192.168.0.1/sda5
Відновлення розділів

Розділи жорсткого диска можна відновлювати повністю (адже точка монтування, по суті, та ж директорія).

ПОПЕРЕДЖЕННЯ: Не намагайтеся відновити кореневий розділ, якщо Ви в нього завантажилися! Це може призвести до втрати всіх даних на всіх розділах, включаючи резервні копії на окремому жорсткому диску! ... rdiff-backup виконають в точності те, що йому вказано ... якщо в бекапе кореневий розділ порожній, то при відновленні буде віддалено весь вміст цього кореневого розділу - точнісінько як в резервної копії.

Для відновлення sda5 з останньої резервної копії необхідно виконати:

# rdiff-backup -r now /media/sdb1/rdiff-backups/192.168.0.1/sda5 /media/sda5
Відновлення коренево розділу

Відновлення кореневого розділу - справа не проста. Як було сказано вище - не допускається відновлення "/", якщо він змонтований. Необхідність даної дії може виникнути в результаті невдалої інсталяції, оновлення системи або її ядра. При правильному виконанні - можливий відкат до попереднього стану системи, і він займе не більше 20 хвилин.

Один із способів відновлення полягає в завантаженні в паралельно встановлену Linux-систему. Далі процес відновлення аналогічний вищеописаної стандартною процедурою (тому що в завантаженою системі відновлюваний кореневий розділ не є кореневим для запущеної системи, а виступає в ролі звичайного пункту монтування). Перевантажити в систему, кореневий розділ якої був відновлений - сама система буде в точності відповідати використаної резервної копії. Цей спосіб - найлегший.

Іншим способом є завантаження з aptosid-live та здійснення відновлення кореневого розділу з "Live-CD" системи (утиліта rdif-backup включена до складу ПО на диску). Якщо ж утиліта не виявлена ​​в комплекті Live-CD, можна при завантаженні в командному рядку grub (Bootoptions, (Cheatcodes)) вказати "unionfs", що дозволить виробляти інсталяцію пакетів в режимі Live-CD. Після закінчення завантаження необхідно виконати в командному рядку:

$ sudo su
# wget -O /etc/apt/sources.list http://aptosid.com/files/misc/sources.list
# apt-get update
# apt-get install rdiff-backup
А тепер здійснимо відновлення:
# mount /dev/sda1 /media/sda1
# mount /dev/sdb1 /media/sdb1
# rdiff-backup -r now /media/sdb1/rdiff-backups/192.168.0.1/root /media/sda1

Примітка: якщо ви не маєте диска aptosid, але маєте Live-CD з підтримкою klik, встановити rdiff-backup можливо за допомогою Klik:

$ sudo ~/.zAppRun ~/Desktop/rdiff-backup_0.13.4-5.cmg rdiff-backup -r now /media/sdb1/rdiff-backups/192.168.0.1/root /media/sda1

Рекомендується кожному спробувати відновлення кореневого розділу на практиці. так як немає нічого гіршого, ніж думати, як все просто і легко, а потім зіткнутися з несподіванкою в аварійній ситуації.

Якщо жорсткий диск був змінений або переформатований, перевірте ще раз UUID (або міток) в / boot / grub / menu.lst (при grub-legacy) або файли в / etc / grub.d (при grub2) та / etc / fstab і змініть відповідним чином. Найпростіший спосіб отримати інформацію для зміни файлів menu.lst і fstab, якщо є необхідність як суперкористувач:

blkid
Резервне копіювання даних інших хостів

Дані з віддаленої машини можна зберігати локально з умовою наявності ssh доступу до віддаленого хосту і достатньої кількості вільного місця на жорсткому диску. На віддаленій машині повинен бути запущений сервер ssh, де при цьому розташований сам хост - значення не має (це може бути і локальна мережа та інтернет).

Уявімо що віддалений хост має такі параметри:
1) 100ГБ жорсткий диск (sda) звичайні точки монтування
2) sda1 використовується як кореневий розділ
3) sda5 призначений для зберігання тимчасових файлів, які ми не включаємо в резервне копіювання
4) sda6 як swap
5) IP адреса 192.168.0.2

Примітка: обидва 100 гігабайтних харда зазвичай не можуть бути зарезервовані на 200 гігабайтному вінчестері зважаючи на брак дискового простору, але оскільки ми не копіюємо sda5 віддаленого хоста, а розділи жорсткого диска зазвичай не заповнені на 100% (хоча покладатися на це не варто) можна порахувати кількість необхідного місця на жорсткому диску і переконатися в його достатності. Кожен раз, коли новий розділ зберігається за допомогою rdiff-backup, необхідно пам'ятати, що створюється нова 'структура' для вкладених файлів, що вимагає нового додаткового простору.

Існує можливість обмежити часовий інтервал зберігання резервних копій (наприклад одним місяцем) і відповідна команда буде розглянута нижче. Звичайно в цьому випадку буде потрібно менше місця, ніж при збереженні резервних копій за річний період. А у випадку, коли необхідно зберігати копії протягом року, також необхідно мати достатню кількість дискового простору.

По-перше необхідно встановити rdif-backup на віддалений хост (відноситься до кожного комп'ютера, з якого Ви маєте намір здійснювати резервування даних, включаючи бекап-сервер).

На локальному комп'ютері виконуємо: Зверніть увагу на використання подвійного двоxкрапoк::

# mkdir /media/sdb1/rdiff-backups/192.168.0.2/root
# rdiff-backup --exclude '/tmp/*' --exclude '/proc/*' --exclude '/sys/*' --exclude '/media/*/*' 192.168.0.2::/ /media/sdb1/rdiff-backups/192.168.0.2/root

Тепер для відновлення директорії на віддаленому комп'ютері можливо ініціювати процес відновлення як локально, так і віддалено.

Відновлення директорії / usr / local / games на віддаленому комп'ютері, ініціалізувавши процес відновлення на ньому ж:

# rdiff-backup -r now 192.168.0.1::/media/sdb1/rdiff-backups/192.168.0.1/root/usr/local/games /usr/local/games

Теж саме, але локально:

# rdiff-backup -r now /media/sdb1/rdiff-backups/192.168.0.1/root/usr/local/games 192.168.0.2::/usr/local/games

Використовується такий же синтаксис, як при відновленні кореневого розділу з Live-CD (віддалена машина завантажена з Live-CD ... приклад - дивись вище).

Автоматизоване створення резервних копій::

Перше, що необхідно для резервування даних з віддаленого комп'ютера, включити доступ по ключах ssh без використання пароля. Йдеться про вхід без пароля з моїм обліковим записом root. Обговорення можливості обмежитися безпарольний виконанням тільки команд rdiff-backup виходить за рамки цієї статті, детальна інформація знаходиться в розділі керівництва "SSH Configuration" . Тут ми розглянемо найпростіший спосіб установки безпарольного логіна, приймаючи політику "повного довіри".

Виконуємо локально:

# [ -f /root/.ssh/id_rsa ] || ssh-keygen -t rsa -f /root/.ssh/id_rsa

Двічі натискаємо 'enter' для збереження порожнього пароля. після цього:

# cat /root/.ssh/id_rsa.pub | ssh 192.168.0.2 'mkdir -p /root/.ssh;\
> cat - >>/root/.ssh/authorized_keys2'

Буде запропоновано ввести пароль root.

Тепер ви можете увійти по ssh на віддалений хост під обліковим записом root, не вводячи пароль, і провести автоматизацію rdiff-backup.

Наступним кроком створимо shell-script, подібний нижче наведеному і містить всі необхідні команди rdiff-backup:

#!/bin/bash
RDIFF=/usr/bin/rdiff-backup
echo
echo "=======Backing up 192.168.0.1 root======="
${RDIFF} --ssh-no-compression --exclude '/tmp/*' --exclude '/proc/*' --exclude '/sys/*' --exclude '/media/*/*' / /media/sdb1/rdiff-backups/192.168.0.1/root
echo "(and purge increments older than 1 month)"
${RDIFF} --remove-older-than 1M --force /media/sdb1/rdiff-backups/192.168.0.1/root
echo
echo "=======Backing up 192.168.0.1 mount sda5======="
${RDIFF} --ssh-no-compression --exclude /media/sda5/myjunk /media/sda5 /media/sdb1/rdiff-backups/192.168.0.1/sda5
echo "(and purge increments older than 1 months)"
${RDIFF} --remove-older-than 1M --force /media/sdb1/rdiff-backups/192.168.0.1/sda5
echo
echo "=======Backing up 192.168.0.2 root======="
${RDIFF} --ssh-no-compression --exclude '/tmp/*' --exclude '/proc/*' --exclude '/sys/*' --exclude '/media/*/*' --exclude '/mnt/*/*' 192.168.0.2::/media/sdb1/rdiff-backups/192.168.0.2/root
echo "(and purge increments older than 1 months)"
${RDIFF} --remove-older-than 1M --force /media/sdb1/rdiff-backups/192.168.0.2/root

Збережемо скрипт під ім'ям "myrdiff-backups.bash" в директорії / usr / local / bin локально (на бекап-сервері), не забуваємо зробити його виконуваючим. Запускаємо його щоб переконається, що скрипт працює.

І в останню чергу прописуємо в crontab (root-овий) виклик скрипта щоденно о 8 годині вечора. Для цього виконуємо від імені root наступне:

# crontab -e
and insert the following line
0 20 * * * /usr/local/bin/myrdiff-backups.bash
Сторінка останний раз переглянута 14/08/2010 0100 UTC