Подходы к созданию резервных копий: cpio/tar, rsync, R1Soft CDP

Создание резервных копий заботит пользователей не одно десятилетие. За это время было разработано множество методов и инструментов. Существующие подходы можно разделить на три группы:

  1. Последовательное копирование всех данных целиком.
  2. Копирование только изменившихся файлов.
  3. Копирование изменившихся блоков файловой системы.

Материал предоставлен VPS.ua

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

Данные, записанные на ленте последовательно единым блоком, должны были быть структурированы. Также нужна была возможность работать с данными внутри блока, не извлекая всё целиком. Так появились утилиты cpio и tar, которые, по сути, последовательно собирают все данные в один файл. Описание структуры директорий и местоположение файлов эти утилиты сохраняют в начале архива. Cpio, кстати, лежит в основе пакетов операционной системы redhat (rpm).

Утилиту tar хотя и называют архиватором, но отдельно практически не используют. Дело в том, что она не производит сжатия данных. Она складывает все нужные файлы, с сохранением структуры директорий в один файл, а для компрессии использует сторонние программы, такие как bzip и gzip. В результате мы получаем файлы в формате tar.gz и tar.bz. Tar и cpio используются и по сей день. Благодаря им многие с тех пор называют операцию резервного копирования архивацией.

Вторая группа - программы, выполняющие, так называемое, инкрементарное копирование.

Метод архивации бесспорно хорош, но заставляет создавать каждый раз полную копию всех файлов. Соответственно, если мы захотим хранить две копии, за сегодня и за вчера, мы будем вынуждены использовать вдвое большее дисковое пространство. А если мы захотим сохранить копии за целый месяц и при этом делать их каждый час, то нам потребуется место для 720 копий! Это будет просто расточительством дискового пространства. Для решения проблемы была разработана утилита rsync. Она не производит сжатия или последовательной записи всех файлов в один, вместо этого она сравнивает исходную директорию с целевой и копирует в целевую директорию только те файлы, которых не хватает или которые содержат отличия. Для создания множества копий, в которых будут храниться только изменения, rsync умеет создавать жесткие ссылки.

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

При повторном создании резервной копии могут быть созданы жесткие ссылки на все файлы уже находящиеся в целевой директории. Все файлы, которые будут замещены новыми, сохранятся и будут доступны через созданные жесткие ссылки. Если создавать наборы жестких ссылок в отдельных каталогах и называть их числами (1, 2, 3…), то мы будем иметь возможность получить доступ к определенной резервной копии целиком, храня повторяющиеся данные только в одном экземпляре.

Изменившиеся файлы rsync определяет, используя алгоритм подсчета контрольных сумм. Отдельно стоит упомянуть, что передача лишь изменившихся файлов, позволяет экономить не только место в хранилище резервных копий, но и снизить объем трафика, проходящего от источника к хранилищу.

Метод rsync хорош, но при наличии сильно нагруженных систем, крайне негативно сказывается на производительности. А попытка создания резервной копии директории с несколькими миллионами файлов просто обречена на проблемы. Такое копирование будет происходить очень долго и создаст колоссальную нагрузку на дисковую подсистему. Для выхода из этой ситуации были разработаны системы создания резервных копий, работающие на уровне блоков файловой системы. Они позволяют не беспокоиться о количестве файлов, которые мы хотим сохранить в резервной копии. А также, в отличие от rsync, такие системы не будут копировать файл размером в несколько гигабайт из-за изменения в нем в нескольких байт.

Одним из примеров такой системы, является CDP от компании Idera (r1soft). Этот продукт существует на рынке достаточно давно и уже успел зарекомендовать себя в корпоративном секторе. В отличие от rsync он работает на сервере-источнике постоянно, отслеживает изменения в блоках файловой системы в тот момент, когда они происходят. Таким образом для дисковой подсистемы он нагрузки практически не несет и в момент начала создания резервной копии, когда rsync проводит ресурсоемкое сканирование файлов, CDP уже знает, что копировать, и приступает незамедлительно.

Аналогично rsync с помощью CDP можно создавать множество резервных копий, которые не будут занимать большой объем дискового пространства. Операции по обслуживанию резервных копий происходят на отдельном сервере, выполняющем роль хранилища, так что для сервера-источника они нагрузки не несут. В дополнение к этому CDP может выполнять компрессию хранимых файлов, поэтому на диске такая резервная копия будет занимать меньше места, чем в случае с rsync.

Настройка создания резервных копий в CDP достаточно гибкая. Можно создавать точки восстановления (срез резервной копии) хоть каждый час. CDP умеет работать также и с базами данных, позволяя восстанавливать не сервер баз данных целиком, а только нужную бд. Стоит упомянуть, что в CDP используется механизмы проверки резервных копий, которые не только обеспечивают надежную передачу данных от источника к хранилищу, но и гарантируют надежность хранения данных в течение продолжительного времени.

Также стоит учесть, что CDP - это комплексное решение с удобным пользовательским интерфейсом. Вам нужно будет только установить агента для создания резервных копий на свой сервер и добавить сервер в панель управления. Вам не нужно будет писать собственные скрипты для rsync, беспокоиться о работающем демоне rsync или его наличии на хранилище (если испробовать протокол SSH, как транспорт).

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

Потестировать этот метод можно здесь.

Фото наших бэкапных хранилищ:

С уважением,
старший системный администратор VPS.ua
Денис Мищенко

Теги:

Смотрите также

Комментарии

О R1Soft CDP по тому наш линуксоид и я сетевик-виндоусятник ничего не слышали. Полез в Интернет и вижу что там довольно не много информации, и сайт у них какой-то, не внушающий доверия. Странно почему в этот обзор попало это программное решение, но другие системы создания резервных копий, которые куда более популярные чем R1Soft CDP упущены.

Эта статья не была призвана сравнить соверменные решения для резервных копий, она показывает эволюцию резервных копий на примере нескольких подходов и к чему конкретно мы пришли.Мы действительно сначала бекапили tar-ом, потом использовали rsync и сейчас остановились на r1soft. Пока счастливы и предлагаем другим тоже восопользоваться им или подобными системами резервного копирования. R1Soft на рынке уже очень давно,
так что это на самом деле не новость.

Длинный текст

Вот ещё одна плохая статья.

Я даже не буду упоминать, что существует, кроме полного и инкрементального, ещё и дифференциальное резервное копирование (оно же бекап). Просто потому, что не хочу переписывать википедию (статья "Резервное копирование"). Вместо этого я пройдусь по ошибкам, искажениям фактов и некоторым особенностям резервного копирования, которые надо знать.

> Метод архивации бесспорно хорош, но заставляет создавать каждый раз полную копию всех файлов. Соответственно, если мы захотим хранить две копии, за сегодня и за вчера, мы будем вынуждены использовать вдвое большее дисковое пространство.

С одной стороны это конечно так, но если только вы не сжимаете свои архивы. Современные алгоритмы сжатия быстро и эффективно сжимают одинаковые файлы. Поэтому реальный прирост размера бекапа двух или более одинаковых состояний будут не очень большим.

> Для решения проблемы была разработана утилита rsync.

Давайте поставим все точки над ё сразу: rsync расшифровывается как "Remote SYNChronization", т.е. "удалённая синхронизация", а задача этой программы -- синхронизация файлов и каталогов в двух местах с минимизированием трафика. Другое дело, что её можно использовать для организации бекапа не удалённой машине. И не надо выдумывать то, чего нет на самом деле.

> Она (rsync -- прим. ком.) не производит сжатия или последовательной записи всех файлов в один

Вообще-то rsync это умеет (man rsync), но по умолчанию не делает.

> Для создания множества копий, в которых будут храниться только изменения, rsync умеет создавать жесткие ссылки.

1) это не поведение по умолчанию
2) естественно это работает только в пределах одного раздела.

> Изменившиеся файлы rsync определяет, используя алгоритм подсчета контрольных сумм.

Опять же это не поведение по умолчанию. По умолчанию rsync использует "быструю проверку" файлов по времени модификации и размеру.

> А попытка создания резервной копии директории с несколькими миллионами файлов просто обречена на проблемы. Такое копирование будет происходить очень долго и создаст колоссальную нагрузку на дисковую подсистему.

Это справедливо в любом случае.

> Для выхода из этой ситуации были разработаны системы создания резервных копий, работающие на уровне блоков файловой системы. Они позволяют не беспокоиться о количестве файлов, которые мы хотим сохранить в резервной копии.

Вот только это никак не решает проблему с большим числом файлов. Почему? А потому что описанный тип файловых систем (т.н. ФС с инодами) может адресовать только блоки. Т.е. один файл никак не может быть меньше 1 блока. Т.е. если даже файл имеет размер в 1 байт, то занимать он будет один блок целиком, хоть он 512б, хоть он 4Кб.

> А также, в отличие от rsync, такие системы не будут копировать файл размером в несколько гигабайт из-за изменения в нем в нескольких байт.

Вообще-то для таких ситуаций и придумали rdiff-backup. Единственное, он использует самый медленный алгоритм rsync, поэтому лучше их использовать в паре: rsync обнаруживает изменившиеся файлы, а rdiff-backup их синхронизирует по списку.

> разработаны системы создания резервных копий, работающие на уровне блоков файловой системы.

С таким подходом на пустом месте мы получаем следующие проблемы:
1) любое изменение параметров файловой системы (например, размер блока) или самой файловой системы заставляют выбросить более ранний бекап в мусорку и начать жизнь с чистого листа. Т.е. был у вас раньше сервер на FreeBSD с UFS2 и случилась с ним беда (допустим сгорел), но бекап остался. И вам дают сервер с GNU/Linux и ext4. А бекап-то накатать не получится -- ФС разные! Проблема на пустом месте!
2) бекапить надо или весь раздел, или потом как-то вычленять файлы. Если бекапить только часть данных не получится -- будут места с неопределёнными данными.
3) часть ФС описывает владельца файла его числовым ID, а часть текстовым. Каждый подход имеет свои подходы к восстановлению. В rsync и другом ПО это можно регулировать. А вот при таком подходе -- нет.

> В отличие от rsync он работает на сервере-источнике постоянно, отслеживает изменения в блоках файловой системы в тот момент, когда они происходят.

Т.е. фактически в памяти висит ещё один процесс, который дублирует mtime для блоков, и потенциально может запороть файловую систему на ровном месте. Более того такой перехват требует права root, а это потенциально ещё одна дыра безопасности. Ещё два минуса.

Ну, и как раньше уже писали, под GNU/Linux есть огромное количество разнообразных программ, которые можно использовать для бекапа.
Приведу краткий список доступного в репе Debian и того, чем пользовался сам:
tar, Dar, Rsync, Rsnapshot, Rdiff-backup, Duplicity, Duplicati, Obnam, Bacula, BackupNinja, BackupPC.
Часть из описанного использует другое для непосредственной работы. В общем на любой вкус и цвет!

Отвечу в целом на ваш комментарий. Да, с помощью стандартного набора утилит можно сделать все. Но на практике все делается крайне редко и чаще всего проблемы решаются по мере их поступления, а не превентивно.

Вы пишете:
> Для выхода из этой ситуации были разработаны системы создания резервных копий, работающие на уровне блоков файловой системы. Они позволяют не беспокоиться о количестве файлов, которые мы хотим сохранить в резервной копии.

Вот только это никак не решает проблему с большим числом файлов. Почему? А потому что описанный тип файловых систем (т.н. ФС с инодами) может адресовать только блоки. Т.е. один файл никак не может быть меньше 1 блока. Т.е. если даже файл имеет размер в 1 байт, то занимать он будет один блок целиком, хоть он 512б, хоть он 4Кб.

--
Как раз решает, так как резервная копия первая проходит практически с линейным чтением всех занятых блоков. А последующие - с копированием только изменений. Таким образом нет затрат времени и ресурсов на поиск разницы. Это достаточно существенно сказывается на нагрузке и производительнсоти.

Бэкап с помощью rsync впс-а с 8ю миллионами файлов занимал 4-6 часов. С переходом на CDP он начал занимать 15 минут. Конечно же это не разница. И конечно же это не означает, что это единственный способ добиться такого результата. В тексте отражен наш, собственный опыт.

> Отвечу в целом на ваш комментарий.

А вы не стесняйтесь, отвечайте на каждый элемент комментария отдельно. Особое внимание рекомендую уделить минусам -- всё-таки именно по ним выбирают или нет ПО. А они с моей точки зрения очень и очень существенные.

> Но на практике все делается крайне редко и чаще всего проблемы решаются по мере их поступления, а не превентивно.

Это вы к чему?

> Как раз решает, так как резервная копия первая проходит практически с линейным чтением всех занятых блоков.

rsync будет в этом случае лишь чуть медленнее, т.к. будет запрашивать наличие файла на сервере. С другой стороны, это будет компенсироваться тем, что rsync будет передавать меньше данных за счёт не полностью занятых блоков. В любом случае тут разница будет в пределах погрешности измерения.

> А последующие - с копированием только изменений.

Внезапно, но rsync поступает так же!

> Таким образом нет затрат времени и ресурсов на поиск разницы.

Вообще-то есть.
Ваш подход тратит время и ресурсы два раза:
1) когда висит в памяти и обрабатывает изменения блоков
2) во время бекапа на запрос изменяемых блоков.

rsync делает это только один раз, запрашивая mtime и размер файла во время бекапа. Это очень быстрая операция, т.к. они берутся напрямую из метаданных ФС.

Таким образом общие затраты времени и ресурсов для вашей схемы будут выше.

> Бэкап с помощью rsync впс-а с 8ю миллионами файлов занимал 4-6 часов. С переходом на CDP он начал занимать 15 минут.

Скорее всего это было вызвано неверным использованием rsync. Я такой вывод делаю на основании того, что 4-6 часов -- это как раз и есть примерное время полного бекапа 10Гб.

В чём именно была проблема сказать точно не берусь, но могу предположить, например, что вы пускали rsync не с быстрой, а с тотальной проверкой, раз уж вы взялись за её описание. Или использовали ФС с разными точностями представлениями mtime или даже без поддержки ctime (встречал такой косяк на виртуалках). Или ещё много чего. Гадать можно долго, пока вы не предоставили полного описания эксперимента. Полного -- это такого, чтобы любой желающий мог его повторить на своём железе.

Однако я могу сделать некоторые теоретические выкладки. Пусть у вас есть 8 миллионов файлов и они занимают 8 Гб. Тогда средний размер файла -- около 1 Кб. Пусть это составляет 2 блока (блоки по 512 байт -- меньше нельзя). Допустим, что в каждом файле был изменён ровно 1 блок. Тогда rsync забекапит все 8 Гб данных, ваша программа -- 4 Гб. При прочих равных, преимущество вашей программы составит 2 раза. И это теоретически наилучший результат. Вы же пишите про 20 раз. Это как минимум странно.

Споры - это хорошо. Но хочу предложить Вам кое-что другое. Перейдите, пожалуйста, по ссылке https://vps.ua/clients/order-nonav/?utm_... и потестируйте CDP Бекап 10ГБ, опишите свои ощущения. И после этого мы сможем продолжить дискуссию равноценно, когда вы уже попробуете этот продукт.

Вопрос к VPS.ua: насколько я понял, с помощью вашего решения можно бэкапить к вам VPS, размещенные у других провайдеров. Где бы почитать про процесс настройки VPS? К себе нужно поставить и настроить какую-то клиентскую часть?

Да, можно. Как только закажете, вам придет подробная инструкция со всеми ссылками. Выглядеть будет примерно так:

Для того чтобы активировать и настроить резервное копирование своего VPS, вам необходимо:

1) Установить Backup Agent на своем VPS согласно инструкции для Linux (CentOS/Fedora), Linux (Debian/Ubuntu) или Windows. Все инструкции лежат по ссылке http://vps.ua/clients/knowledgebase.php?....

2) Добавить ключ верификации внешнего хранилища резервных копий на своем VPS согласно инструкции для Linux или Windows.

3) Активировать резервное копирование для своего VPS в настройках продукта CDP Backups в панели клиента.

В результате для вашего VPS будет активировано ежедневное резервное копирование. Система позволяет хранить до пятидесяти контрольных точек (по запросу мы можем увеличить это число). Восстановление контрольной точки можно произвести в интерфейсе R1soft.

Берите тест и все сами проверите)

Уже похожое обсуждалось, пример работы на серваке http://evromigracija.ru с юридическими услугами было реализовано :)

На эту тему, читал пару статей. На самом деле масса информации, так что ребята кто ищет тот найдет. Всем удачи. А в целом мне кажется, все грамотно расписано.

Прекрасная обзорная статья, подчерпнул вдогонку к циклу статей об облаках на блоге Андрея Хвостова http://ingenerhvostov.ru на который подписан, много нового и интересного. Хотелось бы статей "частности/конкретики". А так, вполне информативно и достойно. Жду по теме другие материалы

Станислав Тигранян

Резервное копирование - наше с вами всё. Впрочем я уже читал подборку материалов на данную тематику на блоге Ивана Кунпана http://biz-iskun.ru о рез. копировании. Так что надеюсь на новые статьи и у вас. Обязательно подпишусь на ваши обновления. Я всегда подписываюсь, если тексты мне интересны. И в ожидании новинок, просматриваю почту...

Хочу сделать на своем блоге http://first-billion.com/ Что-то по данной теме огромное количество информации и не могу дать ладу что к чему!

Статья развернутая, содержит много информации, но для меня слишком уж сложная.

Статья полезная, бекап нужно делать обязательно! Хостинги не несут ответственности за твои данные. Потерял, сам виноват.

По мне так бекап нужно делать обязательно, особенно если хранить фотографии. http://teplodoma-msk.ru/categories/chugu... Статья полезная, спасибо большое.

Статья про бэкапы как раз актуальна. Спасибо

Александр

А я не согласен с мнением что надо автоматом бэкапить. ничего не нужно делать на автомате! Все надо делать ручками. Когда ты сам бэкапишь нужную тебе инфу, ты уверен в этом. а когда все на автомате - есть определенные риски. Может сбой произойти во время копирования или еще чего и инфа скопируется не полностью. Надо все вручную делать и будет вам счастье)

Отправить комментарий

Если вы укажете номера тикетов или имя пользователя, отзыв будет выглядеть убедительнее, а провайдеру будет проще разобраться с вашей проблемой

Подробнее о форматировании

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
5 + 7 13 + 8 плюс 3 0