Подходы к созданию резервных копий: 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
Денис Мищенко

Теги:

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

Комментарии

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

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

Александр

Интересно но не все понятно) http://rmsi.com.ua/ Мне еще учится и учится))

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

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

Если вы укажете номера тикетов или имя пользователя, отзыв будет выглядеть убедительнее, а провайдеру будет проще разобраться с вашей проблемой
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

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

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
5 + 7 19 + 8 плюс 3 1
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.