Резервное копирование только новых и измененных файлов

Обновлено: 07.07.2024

Зачем нужны бэкапы

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

Случайное удаление

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

Поломка носителя

Тут всё сильно зависит от типа неисправности. В некоторых случаях данные со сломанного HDD или SSD восстановить можно за внушительную сумму, но иногда потери безвозвратны (даже за все деньги мира). Также есть риск нарваться на недобросовестных мастеров, которые вместо восстановления данных могут угробить их окончательно.

Неудачное обновление операционной системы

И такое бывает. Например, обновление Windows 10, поступившее в октябре 2018 года, удалило файлы, которые лежали в профильных папках у тысяч пользователей.

Вредоносное ПО

Различные программы-вымогатели, которые шифруют пользовательские файлы и требуют выкуп за их расшифровку. Исследователи и антивирусные компании помогают расшифровать данные и публикуют ключи к некоторым шифровальщикам, но далеко не ко всем. Однако, если на данный момент ключа расшифровки на ваш тип вымогателя нет, есть шанс что он появится в будущем. в таком случае зашифрованный носитель лучше сохранить до лучших времён. Чего точно не стоит делать — это платить вымогателям: в этом случае кроме данных есть риск потерять ещё и деньги.

Кража/утеря компьютера

Компьютер в таком случае удастся вернуть с малой долей вероятности. Ещё меньше шансов, что данные на нём останутся в целости.

Пожар, наводнение, землетрясение

Что нужно резервировать

Для начала нужно определиться с данными, которые необходимо «бэкапить». В первую очередь это те файлы, утеря которых недопустима, во вторую — те данные, на восстановление которых потребуется много времени.

Например, это могут быть:

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

Хоть мы здесь говорим о работе, но не стоит забывать и о личных файлах.

архив фотографий и видео
творческие проекты

Список можно продолжать.

Где лучше хранить резервные копии

На отдельном физическом носителе

Это может быть отдельный жёсткий диск в компьютере (не логический раздел диска). Ещё лучше, если носитель будет съёмным и будет храниться отдельно от компьютера. Это повышает надёжность, но к сожалению требует дополнительных действий во время сохранения резервной копии.

Сервер или облачное хранилище

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

Доступность — облачное хранилище доступно в любое время и с любого устройства (при наличии нормального Интернета).
Гибкость — возможность потреблять ровно такой объем хранилища, который нужен в данный момент, достаточно как правило просто выбрать нужный тариф.

Но помните, что в этом случае нужно крайне внимательно беречь доступы, чтобы никто (особенно злоумышленники) не получили доступ к вашему хранилищу. Поэтому ещё раз напоминаем: важно, чтобы к каждому сервису использовать разные пароли, и также важно, чтобы они были сложные.

Правило 1-2-3

Везде есть свои недостатки и поэтому самый надёжный способ — это хранить важные данные в трёх независимых местах:

Основной носитель, где хранится рабочая копия
Съёмный физический носитель
Сервер или облачное хранилище

«Если информация не сохранена в трёх местах — её не существует», — сказал Питер Крог. Считается, что именно он впервые описал правило «3-2-1» в 2006 году в книге «Управление цифровыми активами для фотографов». Кратко это правило звучит так: делайте минимум три резервные копии, в двух форматах хранения, из которых, минимум одна должна храниться в физически отдельном месте. Не фотографы тоже могут взять на вооружение.

Как делать резервные копии

Руками

Это самый ненадёжный способ, занимает много времени, можно забыть вовремя сделать копию.

Скриптами

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

Пример .bat файла для Windows, который копирует файлы с одного HDD на другой. Копируются только новые и изменённые файлы.

1robocopy D:\work_dir F:\backup /mir /log:backup_log.txt

Обратите внимание флаг /mir обозначает полную синхронизацию папок — это означает, что файлы, удалённые в первой папке удалятся также во второй папке, возможно это подойдёт не всем. Но там есть куча других опций.

Специальными программами

Удобный способ, есть как бесплатный так и платный софт с множеством опций, как сжатие или шифрование бэкапов, встроенное расписание. Самые популярные примеры:

Acronis True Image
Ashampoo Backup Pro
EaseUS

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

Задавайте вопросы в комментариях и делитесь своими историями про бэкапы.

Понравился материал? Поделись с друзьями! Дальше будет больше полезных статей👍

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

↑ Полное, инкрементное, дифференциальное – о методах резервного копирования

А разбираться в методах резервного копирования предлагаю на примере программы AOMEI Backupper. Итак, друзья, когда мы в программе AOMEI Backupper создаём резервную копию Windows, целого диска, отдельных разделов или отдельных папок с данными, в дальнейшем после создания резервной копии сможем использовать для неё некоторые программные возможности. В их числе – создание на базе заданных условий бэкапа новых копий с выбором механизма резервного копирования:

Полная копия;
Инкрементная копия;
Дифференциальная копия.

↑ Полное резервное копирование

Полное – это резервное копирование, при котором снимок операционной системы, диска, раздела или отдельных папок содержит все резервируемые данные. Такие снимки, создаваемые в рамках одной и той же задачи по бэкапу, независимы друг от друга, повреждение одного из них никак не повлияет на другие снимки. Это самый надёжный метод резервного копирования, но, вместе с тем, самый затратный по ресурсам дискового пространства. Например, образ рабочей Windows без особых каких-то громоздких программ и игр будет весить примерно 20 Гб. Если по мере создания новых бэкапов не избавляться от старых, диск-хранилище просто забьётся ими под завязку. Решить эту проблему призваны два других механизма резервного копирования.

↑ Инкрементное резервное копирование

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

Удаление инкрементной копии (или повреждение её вирусами) не будет иметь следствием неработоспособность предыдущих инкрементных копий и первичной полной. А вот последующих – будет. К точкам после удалённой инкрементной копии откатиться мы уже не сможем. В этом плане, конечно, метод инкрементного копирования уязвим, но его сильной стороной является обеспечение отката к разным точкам состояния при минимально занятом дисковом пространстве. Ведь при незначительных изменениях каждая новая копия будет весить пару Мб разницы между ней и предшественницей. Вот как, например, бэкап раздела на скриншоте ниже. Вес в 3,57 Гб, отмеченный сиреневым маркером – это вес полной первичной копии, а отмеченные жёлтым маркером 9,12 Мб и 20,01 Мб – это вес инкрементных копий.

Ещё один недостаток инкрементных копий – более долгий по времени процесс восстановления, чем из полных и дифференциальных бэкапов.

↑ Дифференциальное резервное копирование

Дифференциальное – это такое резервное копирование, при котором полная копия создаётся единожды в начале, а все последующие копии, создаваемые в рамках одной и той же задачи, содержат не все данные, а лишь произошедшие изменения с момента создания первичной полной копии. Ключевой момент здесь – с момента создания полной копии. Тогда как при инкрементом копировании вторая инкрементная копия цепочки являет собой разницу между ней и первой копией, при дифференциальном и первая, и вторая, и третья, и четвёртая, и все следующие дифференциальные копии будут зависимыми только от полной копии. Но никак не зависимыми друг от друга. Удаление или повреждение любой из дифференциальных копий не повлияет на другие копии – ни на те, что создавались до удалённой (повреждённой), ни на те, что после неё.

Дифференциальные резервные копии – это тоже точки восстановления.

Необходимость дифференциальной копии каждый раз сравнивать себя с полной первичной копией, соответственно, влечёт за собой использование большего дискового пространства. На скриншоте ниже сиреневым маркером отмечен размер полной копии и жёлтым размеры дифференциальных бэкапов. Размер последних в районе 450 Мб свидетельствует о том, что между ними произошло немного изменений, тем не менее каждое такое изменение с момента создания полной копии зафиксировано в отдельном порядке. И в отдельном порядке поглощает место на диске.

↑ Какой метод лучше выбрать

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

Но есть же ещё нюанс, друзья. Некоторые продвинутые программы-бэкаперы могут предложить не только тот или иной метод создания бэкапа, но и его применение в тех или иных условиях. Например, у AOMEI Backupper есть 5 схем резервного копирования. Схемы можно включить сразу при создании первичного бэкапа.

При настройке схем нужно поставить галочку «Включить управление дисками». И в выпадающем списке ниже увидим пятёрку гибких решений от AOMEI Backupper.

• «Полная копия» - схема с применением метода полного резервного копирования, при котором по достижении назначенного количества копий старые будут автоматически удаляться;

• «Инкрементная копия» - схема с инкрементным бэкапом. По достижении назначенного числа копий цепь предыдущих копий – полной и зависимых инкрементных – удаляется, уступая место новым цепям;

• «Дифференциальная копия» - схема с созданием полных и дифференциальных копий. По достижении их граничного числа старые удаляются, и происходит всё это с учётом привязки дифференциальных копий к их полным;

• «Управление пространством» - схема с созданием полных и дифференциальных копий, заточенная под удаление старых копий при обнаружении недостатка места на диске;

• «Другие схемы резервирования» - схема с полным резервным копированием и возможностью выбора условий автоматического удаления старых копий.

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

Так вышло, что мне нужно было организовать резервное копирование postgresql базы данных. Никаких облаков — держи SSH и сделай, чтобы все работало и не просило денег. Что мы делаем в таких случаях? Правильно, пихаем pgdump в cron, каждый день бэкапим все в архив и если совсем разошлись — отправляем этот архив куда-нибудь подальше.

В этот раз сложность состояла в том, что по планам база должна была расти примерно на +- 100 МБ в день. Разумеется, уже через пару недель желание бэкапить все pgdump'ом отпадет. Тут на помощь приходят инкрементальные бэкапы.

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

Как и любой разработчик, СОВЕРШЕННО не желающий (на тот момент) разбираться в тонкостях postgres я хотел найти зеленую кнопку. Ну, знаете, как в AWS, DigitalOcean: нажал одну кнопку — получил репликацию, нажал вторую — настроил бэкапы, третью — все откатил на пару часов назад. Кнопки и красивого GUIшного инструмента я не нашел. Если вы знаете такой (бесплатный или дешевый) — напишите об этом в комментариях.

Погуглив я нашел два инструмента pgbarman и pgbackrest. С первым у меня просто не задалось (очень скудная документация, пытался все поднять по старинным мануалам), а вот у второго документация оказалась на уровне, но и не без изъяна. Чтобы упростить работу тем, кто столкнется с подобной задачей и была написана данная статья.

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

Подготовка

Для воспроизведения мануала вам понадобятся два VPS. Первый будет хранилищем (репозиторием, на котором будут лежат бэкапы), а второй, собственно, сам сервер с postgres (в моем случае 11 версия postgres).

Подразумевается, что на сервере с postgres у вас есть root, sudo пользователь, пользователь postgres и сам postgres установлен (пользователь postgres создается автоматически при установке postgresql), а на сервере-репозитории есть root и sudo пользователь (в мануале будет использоваться имя пользователя pgbackrest).

Чтобы у вас было меньше проблем при воспроизведении инструкции — курсивом я прописываю где, каким пользователем и с какими правами я исполнял команду во время написания и проверки статьи.

Установка pgbackrest

Репозиторий (пользователь pgbackrest):

1. Скачиваем архив с pgbackrest и переносим его содержимое в папку /build:

2. Устанавливаем необходимые для сборки зависимости:

3. Собираем pgbackrest:

4. Копируем исполняемый файл в директорию /usr/bin:

5. Pgbackrest требует наличие perl. Устанавливаем:

6. Создаем директории для логов, даем им определенные права:

Postgres сервер (sudo пользователь или root):

Процесс установки pgbackrest на сервере с postgres аналогичен процессу установки на репозитории (да, pgbackrest должен стоять на обоих серверах), но в 6-ом пункте вторую и последнюю команды:

заменяем на:

Настройка взаимодействия между серверами через passwordless SSH

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

Репозиторий (пользователь pgbackrest):

Создаем пару ключей:

Внимание! Указанные выше команды выполняем без sudo.

Postgres сервер (sudo пользователь или root):

Создаем пару ключей:

Репозиторий (sudo пользователь):

Копируем публичный ключ postgres сервера на сервер-репозиторий:

На данном шаге попросит пароль от root пользователя. Вводить нужно именно пароль root пользователя postgres сервера!

Postgres сервер (sudo пользователь):

Копируем публичный ключ репозитория на сервер с postgres:

На данном шаге попросит пароль от root пользователя. Вводить нужно именно пароль root пользователя репозитория!

Репозиторий (root пользователь, для чистоты эксперимента):

Postgres сервер (root пользователь, для чистоты эксперимента):

Убеждаемся, что без проблем получаем доступ.

Настройка postgres сервера

Postgres сервер (sudo пользователь или root):

1. Разрешим «стучаться» на postgres сервер с внешних ip. Для этого отредактируем файл postgresql.conf (находится в папке /etc/postgresql/11/main), добавив в него строчку:

Если такая строка уже есть — либо раскомментируйте ее, либо установите значение параметра как '*'.

В файле pg_hba.conf (так же находится в папке /etc/postgresql/11/main) добавляем следующие строчки:

2. Внесем необходимые настройки в postgresql.conf (он находится в папке /etc/postgresql/11/main) для работы pgbackrest:

3. Внесем необходимые настройки в файл конфигурации pgbackrest (/etc/pgbackrest/pgbackrest.conf):

4. Перезагрузим postgresql:

Настройка сервера-репозитория

Репозиторий (pgbackrest пользователь):

Внесем необходимые настройки в файл конфигурации pgbackrest
(/etc/pgbackrest/pgbackrest.conf):

Создание хранилища

Репозиторий (pgbackrest пользователь):

Создаем новое хранилище для кластера main:

Проверка

Postgres сервер (sudo пользователь или root):

Проверяем на postgres сервере:

Репозиторий (pgbackrest пользователь):

Проверяем на сервере-репозитории:

Убеждаемся, что в выводе видим строку «check command end: completed successfully».

Устали? Переходим к самому интересному.

Делаем бэкап

Репозиторий (pgbackrest пользователь):

1. Выполняем резервное копирование:

2. Убеждаемся, что бэкап был создан:

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

Если вы хотите повторно сделать полный бэкап, то укажите дополнительный флаг:

Если вы хотите подробный вывод в консоль, то также укажите:

Восстанавливаем бэкап

Postgres сервер (sudo пользователь или root):

1. Останавливаем работающий кластер:

2. Восстанавливаемся из бэкапа:

Чтобы восстановить базу в состояние последнего ПОЛНОГО бэкапа используйте команду без указания recovery_target:

Важно! После восстановления может оказаться так, что база зависнет в режиме восстановления (будут ошибки в духе ERROR: cannot execute DROP DATABASE in a read-only transaction). Честно говоря, я еще не понял, с чем это связано. Решается следующим образом (нужно будет малость подождать после исполнения команды):

На самом деле, есть возможность восстановить конкретный бэкап по его имени. Здесь я лишь укажу ссылку на описание данной фичи в документации. Разработчики советуют использовать данный параметр с осторожностью и объясняют почему. От себя могу добавить, что я его использовал. Если очень нужно — убедитесь, что после восстановления база вышла из recovery mode (select pg_is_in_recovery() должен показать «f») и на всякий случай сделайте полный бэкап после восстановления.

3. Запускаем кластер:

После восстановления бэкапа нам необходимо выполнить повторный бэкап:

Репозиторий (pgbackrest пользователь):

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

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

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

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

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

КАК НАСТРОИТЬ БЭКАП

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

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

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

Важность второго момента можно проиллюстрировать так: если ваше резервное хранилище для бэкап-копий размещается на том же сервере, где и основная система, то в случае, если сервер сгорит – сгорит действительно всё. Окончательно и бесповоротно.

Поэтому заботимся о правильном расписании бэкапов и обеспечиваем удаленность хранилища для копий.

ОСНОВНЫЕ КРИТЕРИИ ВЫБОРА ПРОГРАММЫ ДЛЯ БЭКАПОВ

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

эффективность расхода ресурсов: программа должна работать в максимально автономном режиме (не отвлекая вас и не тратя ресурс вашего времени, то есть автоматизирована насколько возможно), с минимально возможной загрузкой ресурсов системы и выполняться за минимально возможное время;
скорость восстановления: ПО должно восстанавливать ваши данные из резервной копии максимально быстро, чтобы не страдали бизнес-процессы; идеальной будет функция работы напрямую с копиями данных;
защита данных и безопасность: программа для резервного копирования обязательно должна обеспечивать вам достаточный уровень безопасности – как криптографическими, так и аппаратными средствами (защита каналов передачи данных в СХД, защита данных во время операции резервного копирования, возможность восстановления прерванной сессии);
гибкость: ПО должно быть одинаково пригодно для всех типов данных (поскольку невозможно прогнозировать, какие из них вы посчитаете критически важными и выберете для копирования в резервное СХД), а также давать вам возможность выбора методов бэкапа и одинаково полноценно функционировать при любом из них.

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

Поговорим теперь о видах бэкапа – полном, инкрементальном и дифференциальном. Они различаются способом копирования и сжатия информации.

ПОЛНЫЙ БЭКАП (FULL BACKUP)

Тут все понятно из названия: каждый раз, согласно заданию на бэкап, создается полная копия всей системы, точнее, всех тех данных, которые вы определили для резервного копирования при постановке задачи. Для уменьшения итогового объема резервной копии все данные сжимаются в архив. Таким образом, в вашем хранилище при полном резервном копировании с заданной периодичностью появляются архивы, где данные в основной своей массе дублируются (поскольку на протяжении долгого времени не изменяются). Это серьезный недостаток, ведь расходуется огромный объем ресурсов (см.п.1 в списке критериев бэкапа): место в хранилище, время создания и процессорное время, вычислительные мощности, наконец, ресурсы трафика при транспортировке архивов в удаленную СХД. И хотя метод полного копирования ранее был очень распространенным из-за высокой надежности, в чистом виде на сегодняшний день он признан малоэффективным. Например, для резервного копирования невысокой глубиной (менее двух недель) или с высокой частотой (раз в сутки, раз в несколько часов) полный бэкап чрезмерно расходует ресурсы.

Немного спасет ситуацию механизм дедупликации – выявление и удаление дублирующихся данных в полных копиях. Он также задается специальными программными средствами как на уровне СХД или сервера, так и на клиенте непосредственно. Статистика в некоторых источниках приводит впечатляющие результаты степени дедупликации – от 90% до 98%.

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

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

ИНКРЕМЕНТАЛЬНЫЙ, ИЛИ ИНКРЕМЕНТНЫЙ, БЭКАП (INCREMENTAL BACKUP)

По сравнению с full backup гораздо экономичнее и быстрее, поскольку в этом процессе копируются только те файлы, которые изменились со времени предыдущего резервного копирования. Исходные данные, записанные изначально, не перезаписываются. Механизм инкрементального копирования прост: в качестве начальной точки бэкапа Х0 выбирается время (например, полночь с воскресенья на понедельник), в которое делается полный бэкап; в точке Х1 (полночь с понедельника на вторник) делается копирование файлов, измененных и/или появившихся с момента Х0; в точке Х2 (полночь со вторника на среду) копируются файлы, измененные/появившиеся с момента выполнения Х1; … в точке Хn происходит завершение цикла и делается следующий полный бэкап.

Этот метод гораздо более экономично расходует ресурсы и места в хранилище, и времени, и трафика передачи данных, по сравнению с другими. Однако при восстановлении данных в случае необходимости из резервной копии происходит поэтапное восстановление из точек Хn-1…Х2, Х1, Х0 – до последнего полного бэкапа включительно, и этот процесс может занять много времени.

ДИФФЕРЕНЦИАЛЬНЫЙ БЭКАП (DIFFERENTIAL BACKUP)

Выигрывает перед инкрементальным в случае восстановления данных – время на эту операцию у него меньше, поскольку сравниваются полные копии Х0 и Хn и не требуется поэтапного восстановления. Однако в части объема пространства для размещения в СХД дифференциальное резервное копирование сопоставимо с полным, поэтому экономии места в хранилище и трафика практически не достигается.

При дифференциальном бэкапе происходит копирование «нарастающим итогом»: каждый измененный файл в каждой последующей точке бэкапа копируется заново. То есть выглядит это как: Х0, Х1, Х1+Х2, Х1+Х2+Х3, … +Хn, Х0+Х(1+…n)

Словом, очень громоздко и сложно при расчете места в СХД.

Понять разницу между инкрементальным и дифференциальным бэкапом достаточно просто. Фактически – она в одном слове. Просто сравните:

инкрементальный обрабатывает файлы, измененные или созданные с момента выполнения предыдущего бэкапа;
дифференциальный обрабатывает файлы, измененные или созданные с момента выполнения предыдущего полного бэкапа.

ДРУГИЕ ВИДЫ РЕЗЕРВНОГО КОПИРОВАНИЯ

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

Его отличает высокая скорость создания, крайняя экономия места и значительно меньшее (в сравнении с инкрементальным и дифференциальным бэкапами) количество избыточных данных. Казалось бы, применять дельту должны все, но этого не происходит, поскольку создание бэкапов таким способом и восстановление информации происходит средствами специального ПО. Кроме того, восстановление из дельта-бэкапа происходит очень долго: данные приходится собирать из мозаики измененных кусочков. Тем не менее, этим методом удобно пользоваться для обеспечения непрерывной защиты данных (когда бэкап файла делается непосредственно после его создания или внесения в него изменений – механизм, который отдаленно напоминает автосохранение в файлах Word’а))) или в случаях пониженной пропускной способности при сохранении резервных копий в удаленном СХД.

Аналогично дельта-блочному бэкапу действует разработанный программистами метод бинарных патчей, при котором копируются частички измененных файлов, но применяется другая база сравнения (в дельте – блоки, в этом методе – биты информации).

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

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

За последние 12-15 лет в технологиях резервного копирования произошло много критических изменений, заставивших пересмотреть эффективность подходов и открыть новые способы. Например, внедрение технологии снэпшотов (snapshots) – моментальных «снимков» файловой системы, из которых можно «склеить» резервную копию, – позволяют в облачных системах делать резервное копирование быстро и безболезненно, не останавливая виртуальной машины. Кроме того, применяясь в облаке, снэпшоты позволяют серьезно экономить ресурс СХД, поскольку на диске клиента они места не занимают.

КЛИЕНТЫ SIM-NETWORKS ВЫБИРАЮТ БЭКАП!

Конечно, если вы любите все делать самостоятельно, для вас не составит проблемы настроить резервное копирование вручную – на своем домашнем компьютере. Правда, даже в этом случае есть частичный риск, ведь что-то может пойти не так, и ценные фотографии, книги, видеозаписи или расчеты ракетной ступени случайно могут не сохраниться или сохраниться с дефектом, который сделает невозможным их восстановление из резервной копии. А если речь идет об офисных машинах? Как быть, если необходимо обеспечить бэкап данных, которые хранит корпоративная инфраструктура? Мы рекомендуем все-таки полагаться не на собственные силы, а на профессионализм хостинг-провайдера. Заказать настройку резервного копирования и пространство для удаленного хранения резервных копий в Германии – это очень просто.

Если вы арендуете мощности в нашей облачной инфраструктуре SIM-Cloud, заказать услугу резервного копирования SIM-Cloud BaaS Backup-as-a-Service, проще простого, в пару кликов. Всё уже настроено и будет подключено автоматически, как только вы дадите команду. Кстати, когда наши инженеры разрабатывали SIM-Cloud BaaS, они проанализировали эффективность разных типов бэкапа и остановили свой выбор на методе инкрементального копирования. Наше резервное копирование в облаке оптимизировано таким образом, что показатель RTO (время восстановления данных из копии) составляет в среднем от 15 до 30 минут в зависимости от объема данных. Облачный BaaS от SIM-Networks соответствует всем заявленным выше критериям высококачественного резервного копирования.

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

Создайте собственный выделенный сервер

Вы можете самостоятельно выбрать, в каком дата-центре организовать хранилище для бэкапов. Первый вариант – локальное хранение: ваши резервные копии хранятся в том же ДЦ, где развернута ваша основная инфраструктура. Это дает возможность ускорить RTO и RPO. Второй вариант – бэкапы отправляются на хранение в дата-центр, удаленный от того, в котором развернута основная инфраструктура. Восстановление данных в этом случае будет происходить немного медленнее, но фактор безопасности выше. Если вы сомневаетесь, какой вариант выбрать, обратитесь в нашу службу Customer Care – вам помогут подобрать оптимальное решение.

А приверженцам классического «железа» мы предлагаем аренду удаленного хранилища для резервных копий: надежного, безопасного, высокотехнологичного. И, разумеется, наши высококвалифицированные эксперты поддержки помогут вам настроить необходимую периодичность, глубину и другие параметры резервного копирования вашей системы.

Читайте также: