резервное копирование 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
    Метки:
    Поделиться публикацией
    Комментарии 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

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