Пользователь
0,0
рейтинг
8 февраля 2009 в 21:34

Администрирование → резервное копирование rsync-ом

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

Зачем нужно делать резервные копии важных данных?


Как сказал Воланд в «Мастер и Маргарита», ужасно не то, что человек смертен, а то, что он внезапно смертен. То же самое верно относительно жёстких дисков. У меня за мою жизнь сдохло, кажется, всего 2 НЖМД, один сдох внезапно (очень ценные данные были утеряны), другой — почти внезапно (удалось восстановить часть данных), ситуация среди моих знакомых в среднем отличается не сильно. Статистика смерти винтов есть куда менее субъективная, от гугла — в среднем винт живёт несколько лет, и в 60% случаев винты дохнут внезапно, даже для S.M.A.R.T.

Кроме аппаратных, есть ещё и программные причины утери данных — однажды вирус WIN95.CIH снёс первые несколько мегабайт диска, включая FAT, что привело к полной недоступности данных. Ушёл месяц яростного программирования и лазанья с DiskEdit, чтобы в условиях отсутствия Интернета разобраться со структарами FAT-а и восстановить их. Однажды Patrition Magic завис при переносе раздела. Однажды при работе
Partition Magic-а отключили электричество в щитке на лестничной площадке. В последних двух случаях важные данные не потерялись — но это просто везение. Если вы подключены к сети, то есть вероятность взлома и уничтожения важных данных злоумышленником. От такого рода повреждений RAID-массив уже не спасёт.

Как оценить целесообразность бэкапа?


Есть такое понятие, как жёсткость риска — это вероятность возникновения риска, помноженная на стоимость риска в деньгах. Стоимость риска в данном случае — это то, сколько ты готов был бы заплатить денег за восстановление всей утеряной информации. Оценим вероятность риска снизу. Оценить я могу только аппаратные сбои, ибо остальной статистики у меня нет, да и этой причины для меня уже
было достаточно. Вероятность смерти жёсткого диска за 3 года — не менее 24% в любом случае, независимо от того, новый он или нет. Вероятность, что смерть будет внезапной, как я уже писал, 60%. Итого вероятность внезапной смерти за 3 года — 14%. Если используются два ЖД без зеркалирования, вероятность смерти хотя бы одного из них за этот период — 26%.
Конечно, нужно учитывать и ценность данных на этих дисках — у меня 2 ЖД с ценными данными (потеря любого фатальна) и один с музыкой и фильмами — расстраиваться о утери коллекции избранной мною музыки буду, но переживу.

Когда-то я был студентом и порой жил на 600 рублей в месяц, но теперь я могу позволить себе некоторые вложения в безопасность данных. Сегодня я купил внешний (USB) жёсткий диск на 320 гигабайт, и это удовольствие обошлось мне в 3000 рублей. Почему жёсткий диск? Потому, что данных у меня много — только дорогие моему сердцу фотки занимают гигабайт этдак 40. Да и времени на это тратить много не хочется и хотелось бы, не сортируя всё то, что накопилось за многие года на «важные — неважные» забэкапить вообще всё, кроме музыки и фильмов. Почему внешний? Возможность хранить отдельно от компьютера на случай кражи (хотя это более актуально для ноутбуков), не присоединённым к компьютеру (на случай ошибки, фатальной для данных).

Безопасность.


Я не параноик, но жёсткий диск содержит данные, безопасность которых нужна не только мне — например, совсем не обязательно попадать в руки посторонних фотографиям знакомых девушек в стиле «ню». Соответственно, диск шифруем — я зашифровал весь. В debian всё делается из коробки за несколько минут и потому я нисколько не сомневаюсь, что смогу потом с лёгкостью эти данные восстановить, главное — не забыть записать используемый каскад алгоритмов и подсказку к паролю на бумажке и хранить её в коробке с винтом. Использование сторонних коммерческо-крякнутых средств я бы очень не рекомендовал.

Приступаем.


Я, не долго думая, решил забэкапить все неиспользуемые (но те, которые на всякий случай лучше не терять) разделы целиком, для теста взял раздел с когда-то установленным WIN98:

# cp /dev/hda1 /mnt/backup/images/
тестируем:
# mkdir /mnt/hda1-backup-test
# mount /mnt/backup/images/hda1 /mnt/hda1-backup-test -o loop
# ls /mnt/hda1-backup-test/
boot.ini io.sys ntdetect.com (и так далее)


Ура! Работает!

Так как рабочие данные у меня находятся в файловых системах ext2 и ext3, хочется использовать тот факт, что аттрибуты файлов в ext2/ext3 могут содержать информацию о его бэкапе. Однако, dump использовать крайне не рекомендуется на смонтированных файловых системах — www.rhd.ru/docs/manuals/enterprise/RHEL-4-Manual/admin-guide/s1-disaster-rhlspec.html, dump.sourceforge.net/isdumpdeprecated.html. Появляется огромный выбор между общими технологиями бэкапа — tar, cpio, backup-manager, bacula и так далее, но я пока остановился на rsync + cp — ибо результат можно будет прозрачно прочитать где угодно, ничего не распаковывая и не считывая все инкрементальные архивы.

$ sudo rsync --archive --one-file-system /etc /home /root --delete /mnt/backup/rsync/`date +%F--%H-%M`

Нужно сохранить несколько последних бэкапов? Пожалуйста, используем то, что параметр --link у cp создаёт жёсткую ссылку на файл вместо его копирования.

$ sudo rsync --archive --one-file-system /etc /home /root --delete /mnt/backup/rsync/latest/
$ sudo cp --archive --link /mnt/backup/rsync/latest/
/mnt/backup/rsync/`date +%F--%H-%M`


Проверяем:

$ ls /mnt/backup/rsync/
2008-04-03--04-29 2008-04-03--04-34 latest


Хочется увидеть различия с бэкапом? «Эмулируем» копирование текущего состояния в состояние бэкапа.

$ sudo rsync --archive --dry-run --verbose --one-file-system /etc /home /root --delete /mnt/backup/rsync/latest/

Хочется увидеть различия между бэкапами? Аналогично.

$ sudo rsync --archive --dry-run --verbose --delete
/mnt/backup/rsync/2008-04-03--04-41/
/mnt/backup/rsync/2008-04-03--04-29/


Вот и всё.

Источники:
О шифровании: aiz-linux.blogspot.com/2007/11/gnulinux.html
О винтах: habrahabr.ru/blog/hardware/24009.html,
mydebianblog.blogspot.com/2007/11/blog-post.html
О rsync и не только: www.mikerubel.org/computers/rsync_snapshots

Также можно посмотреть:
rsnapshot — тоже использует rsync и жёсткие ссылки, лучше подходит для резервного копирования на несъёмный носитель или в сеть: habrahabr.ru/blogs/linux/45912
lost_shadow @lost_shadow
карма
19,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Администрирование

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

  • 0
    почерпнуть
    • 0
      Спасибо. На момент, когда вы оставляли этот комментарий, такого текста у меня уже не было. Нужно было сначала доработать текст в черновике, и только потом выкладывать. Но это — моя первая заметка здесь, прошу быть снисходительным.
      • 0
        Я ошибся. Поиск по сайту не сработал корректно.
        • 0
          Вам плюсы по-любому =). Страницу вроде обновлял, но в следующий раз буду внимательнее.
          • –3
            Спасибо! Если будет кармы не меньше пяти — перенесу это в тематический блог.
      • +1
        >не обязательно попыдать в руки
        чего попы? :)
        • +3
          Да-да, вот на этих самых фотографиях и попы: "… попы… знакомых девушек ...".

  • 0
    Советую посмотреть также в сторону rsnapshot.
    • +2
      Да, именно это я и написал в конце, уже после публикации поста, но до вашего комментария.
      rsnapshot всё же сложнее для конфигурирования и есть более специфичная утилита, нежели знакомые многим rsync и cp. Также я по ману не нашёл, как конфигурировать rsnapshot так, чтобы директории именовались датами. Специфичная она в том числе и потому, что заточена на автоматическое резервное копирование, у меня же бэкап ручной и проходит в несколько этапов.
      Я любопытный и мне хочется значить, что данные на моём компьютере меняются именно так, как, по моему мнению, должны. Поэтому сначала я запускаю срипт — с ключом --dry-run, чтобы понять, что изменилось с момента последнего бэкапа. Затем изучаю разницу, и, если надо, добавляю шаблоны в --exclude (например, /home/olya/.mozilla/firefox/t4nr1bs3.default/Cache/ или /home/guest/.thumbnails/).
      Только после этого я запускаю настоящее копирование.
  • 0
    На FreeBSD рекомендуется dump/restore на снимках файловой системы и использовать инкрементное резервирование для экономии места на носителях. Возможно зеркалирование разделов по сети (gmirror+ggated) и шифрование на лету (geli).
    • +1
      ext3 официально поддерживает снимки? В гугле находил информацию о проблемах с этим, как дело обстоит сейчас — не в курсе.
      • 0
        Нет, не поддерживает. Через менеджер логического раздела с ext3 можно получить снимок блокового уровня. Он менее эффективен (ext3-раздел должен быть подключен в режиме «ro», да и по размеру), чем моментальный снимок живой (режима «rw») файловой системы UFS2 FreeBSD.
        Ситуация с ext4 аналогичная как и с ext3.

        Экспериментальная btrfs поддерживает моментальные снапшоты и снапшоты снапшотов.
  • 0
    Раз уж затронули тему, хочется по-нубски спросить: во FreeBSD 7 на UFS чем лучше всего сделать снимки разделов для быстрого восстановления если что?

    А под виндой реально такое осуществить вообще, или проще по-старинке Norton Ghost использовать?
  • +1
    Снапшоты можно делать на уровне lvm'а.
  • 0
    Отличная статья, помню делал такое на сервере. Ночью BackUP производился по сети через rsync.
    Кстати, образ можно снимать с диска целиком, и монтировать его по разделам через loop устройства.
    Вот ТУТ написано как ЭТО делать и как можно восстановить данные при падении HDD
  • 0
    Для бэкапов в стиле rsync и сохранения истории изменений советую rdiff-backup.
    www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/examples.html
    • 0
      Я тоже за rdiff-backup. Никаких извращённых скриптов не нужно, всё из коробки есть.

      Хотя… На днях я начал переводить сервера на backuppc.
      • 0
        А почему, если не секрет?
        • +1
          для rdiff-backup я не нашёл web-морды. Он у меня всё ещё работает, я им даже OpenVZ контейнеры умею бэкапить так, что vzdump восстанавливать может, но это всё равно утилита не для постоянного использования — нет пульта управления. В Backuppc я вижу сколько какой хост занимает места в архиве, сколько места у меня осталось, что запланировано, сколько заданий одновременно запущено, есть ясность с полными/инкрементальными копиями. В общем, наглядность.

          backuppc мне меньше нравится в плане задания времени запуска бэкапов, rdiff-backup проще сконфигурировать чтобы бэкапил только то что нужно. Но наличие единого центра управления бэкапами очень здорово упрощает жизнь. А транспорт для бэкапов тот же rsync + ssh.
          • 0
            Хм. А backup-ninja? У меня единый сервер проходит по всем нодам, делает по ssh дамп баз данных на них и затем утаскивает все по rdiff-backup. Потом тарит получившееся и заливает его на фтп резервного сервера. Все делается по крону, вэб-морды нету для бэкапов в принципе.
            Также жутко рад — на бэкапящихся машинах нет никаких скриптов для бэкапа, все делается централизовано. Если интересно такое решение — могу показать.

            Ах да, по окончанию бэкапа шлется письмо со статусом. Там же можно и посчитать занимаемое бэкапами место.
            • 0
              Я примерно так и сделал, но к rdiff-backup у меня приниципиальная неприязнь из-за большого количества файлов. Очень хочется иметь на выходе один файл для полного бэкапа и по одному для инкрементального. Поэтому я смотрю в сторону утилит, работающих с dar.
              • 0
                Будет время — посмотрю на www.backup-manager.org. Список возможностей мне нравится.
                • +1
                  Язык сайта несколько напрягает
              • 0
                У меня статья была про бэкап в домашних масштабах с помощью подручных средств :)
                Если ищите серьёзный инструмент, посмотрите ещё в сторону ru.wikipedia.org/wiki/Bacula, возможно, это то, что вам нужно.
  • 0
    Я уже давно использую вот такой скрипт для инкрементального резврвного копирования. Позволяет держать 10 последних копий в архиве, используя жёсткие ссылки (hard links)
    #!/bin/bash
    if [ -n "$1" ] ; then
    	FROM=$1
    else
    	FROM=/home/username
    fi
    
    if [ -n "$2" ] ; then
    	TO=$2
    else
    	TO=/mnt/arc
    fi
    
    LINKTO=--link-dest=$TO/`basename $FROM`.1
    OPTS="-Ca --delete --exclude-from=$FROM/bin/rsync-excluded -delete-excluded"
    NUMBER_OF_BACKUPS=10
    
    
    find $TO -maxdepth 1 -type d -name '*.[0-9]'| sort -rn| while read dir
    do
    	this=`expr match "$dir" '.*\([0-9]\)'`; 
    	let next=($this+1)%$NUMBER_OF_BACKUPS;
    	basedirname=${dir%.[0-9]}
    	if [ $next -eq 0 ] ; then
    		 rm -rf $dir
    	else
    		 mv $dir $basedirname.$next
    	fi
    done
    rsync $OPTS $LINKTO $FROM/ $TO/`basename $FROM.0`
    
  • 0
    a чего никто про backuppc не сказал?!
  • 0
    под оффтопиком rsync кстати тоже сносно работает — удобно для раскладывания бэкапов по разным серверам.
  • 0
    Для тех кто любит GUI есть классная утилитка GAdmin-Rsync

    А в целом backup с rsync самый удобный
  • 0
    и от себя добавлю другие варианты :)

    tar cvpjf /mnt/backup/all.tar.bz2 / --exclude /proc --exclude /sys --exclude /tmp --exclude /var/tmp --exclude /usr/tmp --exclude /mnt
    Бэкап полной системы.

    Если надо восстановить отдельный файл

    tar -xjvf <имя архива> <имя файла (с путём), который нужно распаковать>
    Leading slash при запаковке убирается, поэтому нужно писать так, например:
    tar -xjvf all.tar.bz2 etc/crontab

    ну и класическое:

    cp -a /mnt/sda /mnt/sdb

    rsync -ax /mnt/hda1 /mnt/hda2 (пишу на всякий пожарный =) )
  • +1
    Хотел почитать про шифрование, но www.plati.ru/asp/pay.asp?idd=664867 — не работает :(
    • +1
      извините, не ту ссылку кинул :)
      вот aiz-linux.blogspot.com/2007/11/gnulinux.html — пишет что нет такого блога
      • 0
        Я считаю наиболее прогрессивным — LUKS в dm-crypt, потому могу посоветовать такие ссылки на русском языке:

        www.opennet.ru/base/sys/crypt_disk.txt.html, раздел про LUKS — там разве что пакеты устанавливаются emerge-ом, да и под шифрование в примерах попадает весь диск, а не раздел, будьте осторожны!

        kmb-tips.blogspot.com/2008/04/gnulinux.html — можно использовать как шпаргалку по нужным командам, статья очень похожа на ту, на которую не работает ссылка.

        belgorod.lug.ru/wiki/index.php/Создание_шифрованного_тома_в_Linux — неплохо расписано про LUKS, но я бы использовал шифрование aes-cbc-essiv:sha256, а не aes, как написано в примерах.

        ключевые слова для гугла: LUKS, cryptsetup, luksFormat, luksOpen
        • +1
          Спасибо, буду изучать.

          p.s.: В последнее время, как-то страшно хранить инфу в открытом виде
  • 0
    Посмотрите еще для десктопа — Unison, для сервера — duplicity.
  • 0
    для скопа, инфа о работе алгоритма, доступно: www.openbsd.ru/docs/rsync.html

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