Руководствах по копированию

Резервное копирование данных в домашних условиях

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

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

1. От чего защищаемся?

1. Физические сбои: мертвый жесткий диск или SSD-носитель.
2. Логические сбои: случайное удаление или неверная правка, повреждение приложением, сбой файловой системы.
3. Вирусы, уничтожающие данные (как классические вандалы, так и современные шифраторы).
4. Полная утрата компьютера (пожар, затопление, кража, изъятие полицией и т.п.).

Важно понимать, что одно-единственное решение не защитит от всех угроз. Например, защита от сбоев оборудования защищает от (1), но не от (2)-(4). Кроме того, некоторые решения, используемые профессионалами, в домашних условиях неоправданно дороги или сложны в использовании (да, я в курсе, как классно подключить NAS по iSCSI, но попробуйте предложить такое решение своей бабушке). Поэтому придется применять несколько решений одновременно.

2. Что потребуется?

• Дополнительный жесткий диск в ПК (очень желательно, чтобы их было минимум два).
• Две или более флэшки достаточного объема (32/64/128 Гб и более). Рекомендуется USB3 (и удостоверьтесь, что это истинная скорость, а не цифирки на интерфейсе к улиточно-медленной памяти, как у самых дешевых моделей).
• привод DVD-RW.
• Подключение к облачному хранилищу типа Google Drive, Microsoft OneDrive или аналогичным.

3. Как защищаемся? Общие концепции

Создаем резервные копии данных как на внешних носителях, так и в облаке. Таких копий должно быть минимум две (в дополнение к оригиналу).

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

4. С чего начнем?

Первый и очень важный шаг: анализ и реструктуризация своих данных.

Типичная ошибка в домашних условиях – использование «Моих документов» и рабочего стола для хранения данных. Категорически не следует этого делать. Во-первых, эти локации являются частью индивидуального профиля пользователя. В определенных случаях (таких как полная переустановка или сброс ОС, необходимость форматирования системного раздела) он может быть утрачен вместе со всеми данными. Во-вторых, каша в этих локациях ведет к невозможности быстро и эффективно создавать резервные копии.

Для хранения данных следует создать отдельные директории, полностью независимые от операционной системы. Если в компьютере есть только один диск C:, его следует сократить до разумного минимума (оптимально для Windows 10 – 80-100 Гб) с помощью Disk Management. Высвободившееся место отдаем под новый раздел – D:.

На новом разделе создаем папки для хранения данных. Следует выделить две их категории: меняющиеся и не меняющиеся (архив). Для чего? Подходы к копированию этих данных разные.

• Меняющиеся: разнообразные документы (статьи, отчеты, презентации, графика и т.п.) Размер папок с такими данными обычно не превышает нескольких гигабайт. Если больше – задумайтесь над структурой еще раз.
• Не меняющиеся или меняющиеся редко: например фотографии или библиотека.

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

Скачайте и установите на компьютер архиватор 7-Zip или аналогичный. Формат архивации должен поддерживать шифрование как содержимого, так и имен файлов (имена файлов невозможно зашифровать, например, в zip-архиве).

Последнее, что нужно для подготовки – установка в ПК дополнительного жесткого диска и его форматирование как E: В ноутбуке это обычно невозможно, так что данный шаг придется пропустить. Как вариант, вместе с ним можно использовать внешний постоянно доступный дисковый накопитель (домашняя NAS-система, жесткий диск USB и т.п.), если это для вас приемлемо.

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

5. Защита первая: никто не забыт и ничто не забыто

Как? Путем фонового запуска программы, создающей зеркальную онлайн-копию на другом диске.

Зачем? Защищаемся от физических и логических сбоев на основном диске.

Что? Все категории данных на ПК.

Важно! Метод не защищает от вирусов и утраты компьютера.

В Интернете можно найти много программ, позволяющих зеркалить данные на втором диске. Задания резервного копирования могут выполняться как вручную, так и автоматически. Здесь, однако, я опишу простейший способ, опирающийся только на встроенные инструменты ОС: команду robocopy и Планировщик заданий.

а) Создаем на диске Е: текстовый файл с расширением .cmd. Записываем в него набор команд robocopy в формате

robocopy D:РАБОЧАЯ_ПАПКА E:РЕЗЕРВНАЯ_ПАПКА /xo /e /purge
Команда полностью синхронизирует содержимое рабочей и резервной папки, копируя в резервную папку изменившиеся файлы и удаляя из нее те, что отсутствуют в рабочей. Возможная проблема: из-за разнобоя в кодировках robocopy может не распознать кириллическое имя папки. В этом случае придется называть папку латиницей. На рабочем столе можно сделать ярлык на нее, названный по-русски.

При желании можно усложнить команду, добавив, например, сохранение протокола копирования в файл. Robocopy /? вам в помощь.

б) В Планировщике заданий создаем новое задание, заключающееся в вызове этого cmd-файла. Частота исполнения задания зависит от ответа на вопрос, заданный в предыдущем разделе: сколько именно своей работы вы можете потерять? Однако помните, что если вам потребуется вернуться к старой версии только что измененного файла, при слишком частом копировании она уже может оказаться затертой. Ищите баланс.

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

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

Данный метод можно применять и в том случае, если у вас нет второго жесткого диска, но на существующем достаточно места для создания дополнительного раздела (т.е. C:, D: и E: будут на одном физическом носителе). Однако это не защищает от сбоя самого диска.

6. Защита вторая: все свое ношу с собой

Как? Оффлайн-копии архивов данных на внешних флэшках.
Зачем? Защищаемся от всех угроз.
Что? Только меняющиеся данные.

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

Важно! Флешку для резервного копирования категорически нельзя использовать для других целей. Никогда не подключайте ее к другим компьютерам, например, для переноса данных с домашнего ПК.

Данный метод очень прост:

а) Создаем полный архив папки с данными средствами 7-Zip или иного архиватора. При архивировании обязательно выбираем опции шифрования как содержимого, так и имен файлов.

б) Копируем архив на две или более съемных флэшки.

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

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

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

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

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

7. Защита третья: Старший Брат помнит о вас

Как? Копирование архивов на облачный диск.

Зачем и что? То же самое, что и в предыдущем пункте.

Имея архив, скопированный на флэшку, копируем его также в облачное хранилище (типа OneDrive). Точно так же можно держать там несколько последовательных архивов одной и той же папки.

Зачем вообще нужны флэшки, если можно просто скопировать файлы в облако? Очень просто: данные в облаке часто синхронизируются с вашим компьютером. Если вирус или злоумышленник получит доступ к вашему компьютеру, он удалит или зашифрует данные в облаке точно так же, как и на локальном компьютере. Кроме того, данные в облаке (особенно в бесплатном) вам не принадлежат. Вы не знаете, кто и как может получить к ним доступ и удалить их. Вы также можете банально утратить доступ к своему аккаунту из-за потери пароля, хакерского взлома или принуждения раскрыть пароль со стороны правоохранительных органов. Флэшка в шкафу у тещи этим проблемам не подвластна.

Важно! Всегда убеждайтесь, что копия архива успешно скопирована в облако.

8. Защита четвертая: зеркало вечности

Как? Копирование на внешние DVD-R диски.

Зачем? Баланс между ценой и надежностью хранения объемных данных.

Что? Неизменяемые данные большого объема (например фотографии).

В современном мире носители информации достаточно дешевы. Тем не менее, в ситуациях, когда объемы даже личных данных типа фото- и видеоархивов могут свободно достигать терабайтных размеров, запись на матрицу DVD-R по-прежнему остается вне конкуренции по соотношению цена/объем. Для записи можно использовать бесплатное ПО типа ImgBurn. С учетом того, что многие модели современных системных блоков, равно как и ноутбуки, не поддерживают встроенные DVD-приводы, может потребоваться покупка внешнего с интерфейсом USB. При этом особенно гнаться за скоростью передачи данных незачем: основным ограничением является скорость записи на диск. USB2 вполне достаточно.

Те, кто генерирует такие объемы данных, и без того знают о DVD-R, так что здесь метод приведен только для комплекта.

Важно! DVD-диски неустойчивы к огню и дыму. Следует хранить их в герметично закрываемых емкостях либо индивидуальных пластиковых конвертах. Емкость с центральным шпинделем следует располагать так, чтобы диски стояли вертикально. В противном случае они могут банально слипнуться (особенно если не трогать их несколько лет), а слой носителя окажется поврежденным при их разделении.

9. Защита пятая: а ты кто такой?

Как? Контролируемый доступ к папкам с данными на запись.
Зачем? Чтобы максимально обезопасить рабочий набор данных.
Что? Любые данные на рабочем диске.

Данный метод не относится к резервному копированию. Наоборот, он предназначен для максимальной защиты рабочих данных от вирусов, ворующих и шифрующих данные. Он специфичен для компьютеров под управлением Windows 10, защищенных антивирусом Windows Defender (бесплатен, встроен в ОС).

Важно! Категорически не рекомендуется держать в одной операционной системе два и более антивирусов, работающих в режиме защиты в реальном времени. Если вы хотите применить этот метод, но у вас на компьютере установлен другой антивирус, его следует удалить и включить защиту Windows Defender.

Основной проблемой с защитой от вирусов-шифраторов является то, что они действуют от вашего имени. Они имеют тот же самый доступ к файлам, что и вы сами. Если вам не повезло поймать свеженький шифратор, еще не известный антивирусу, он сможет сделать с вашими данными все, что ему заблагорассудится. Даже контроль доступа правами NTFS (если вы знаете, что это такое) и эвристика антивируса вас не спасут.

Поэтому в новых версиях Windows 10 встроенный антивирус имеет опцию, позволяющую разграничивать доступ на уровне процессов. Иными словами, вы можете разрешить доступ на запись к папке с документами пакету MS Office, но не разрешить всем остальным. Вирус-шифратор обычно создает свой собственный процесс, а потому при попытке что-то изменить в защищенной директории будет остановлен антивирусом, даже если тот не знает, что это вирус.
Контроль доступа к данным в Дефендере изначально отключен, его нужно включать вручную. По умолчанию защищается папка «Мои документы» и еще несколько предопределенных мест. Свои папки вам нужно добавлять вручную.

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

10. Краткое резюме

Итак, мы имеем четыре метода резервного копирования и один дополнительной защиты:

• зеркальная копия на другом диске/разделе;
• архив на флэшке;
• архив в облаке;
• зеркальная копия на DVD;
• контроль доступа к файлам Windows Defender.

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

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

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

Удачи. Желаю, чтобы вам никогда не пришлось проверять, насколько надежно вы на самом деле себя защитили.

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

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

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

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

Типы резервного копирования

Резервное копирование может быть таким же простым, как копирование файла из одного места в другое, например, с жесткого диска на съемный USB-накопитель. Но арсенал инструментов в вашем распоряжении может гораздо больше. То, что вам нужно, определяет, какой тип резервного копирования вы должны использовать.

Выберите файлы и папки

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

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

Для этого есть множество бесплатных программ, включая встроенную в Windows 10 функцию резервного копирования и восстановления – её можно найти в меню «Пуск» → Параметры → Обновление и безопасность → Резервное копирование. Она позволяет создать полный образ системы или даже создать диск для восстановления, на случай если Windows выйдет из строя.

Образом системы является полная копия всего диска системы Windows, так что если вам когда-либо придётся его восстановить, это будет именно так, как это было в день резервного копирования.

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

Облачное хранилище и службы синхронизации файлов

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

Внесенное изменение в файл будет автоматически отправлено на все другие компьютеры, использующие учетную запись, даже в других операционных системах. Крупные имена в этой области включают Dropbox, Google Drive и Microsoft OneDrive. Все сервисы предоставляют несколько гигабайт онлайн-хранилища бесплатно, но вы можете получить гораздо больше, заплатив ежемесячную или годовую плату.

Онлайн резервное копирование

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

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

Установите программное обеспечение на ПК, скажите ему, какие файлы/папки необходимо сохранить, а всё остальное оно сделает в фоновом режиме. Поскольку хранилище подключено к сети, вы обычно можете читать файлы через браузер или восстанавливать файлы в других системах по мере необходимости.

Известные бренды: iDrive, SOS Online Backup, Acronis True Image и Carbonite.

Клонирование полного образа диска

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

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

Создание образа/клона – отличный способ сделать резервную копию нового компьютера. Затем, когда он начинает работать плохо (это происходит со всеми компьютерами), вы можете вернуть диск к его первоначальным настройкам. Имейте в виду, однако, что это похоже на возврат к заводским настройкам – хотя и к вашим собственным – это означает, что восстановление не будет включать в себя данные, накопленные после первоначальной съёмки образа. Эти данные должны быть зарезервированы отдельно. (Да, у вас должно быть два набора резервных копий. Я уже упоминал об избыточности?)

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

Стороннее программное обеспечение для создания образа диска включает в себя бесплатные DriveImage XML, Clonezilla или Macrium Reflect Free; или попробуйте высококачественные платные решения, если вы планируете клонировать на постоянной основе.

Выбор места резервирования

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

Внешние диски

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

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

CD / DVD / Blu-Ray диски

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

CD-Recordables (CD-R) могут хранить только одну порцию данных (около 700 МБ, максимум) – это настолько мало, что будет похоже на использование дискеты. DVD-R намного лучше – 4,7 ГБ, но даже двухслойные DVD-R объемом 8,5 ГБ не смогут вместить всю вашу коллекцию музыки и фотографий.

Двухслойные диски Blu-ray (BD-R) хранят до 50 ГБ, но цены соответствуют этому. И даже при такой емкости резервное копирование на диски будет казаться бесконечно медленным по сравнению с быстрыми жесткими дисками и флешками. Кто хочет постоянно менять местами диски?

Плюсы: дисковые носители дешевы (если они есть в наличии) и очень портативны (всегда рекомендуется хранить резервные копии данных вне офиса).

USB флэш-накопители

Небольшие USB-накопители почти так же дешевы, как и диски. Их преимущество в том, что они ультрапортативны. Может быть, слишком портативны, так как их легко потерять. Но спрятать одну флешку объемом несколько ГБ в сейфе легче, чем хранить оптические или жесткие диски. Некоторые USB-накопители даже предназначены для защиты данных, что делает их более безопасным местом для ваших данных.

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

Сетевое хранилище (NAS)

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

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

В большинстве блоков NAS есть FTP, удаленный доступ в режиме онлайн, элементы управления безопасностью и различные конфигурации RAID для определения того, как диски хранят ваши данные (избыточно или распределено по дискам). Некоторые имеют несколько портов Ethernet, Wi-Fi и USB. Некоторые захватывают ввод с сетевых цифровых видеокамер. Варианты кажутся почти бесконечными, поэтому стоит выбрать подходящий вариант для дома или офиса.

Копирование в облако

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

Если у вас только несколько небольших файлов для хранения, и у вас, вероятно, есть учетная запись Google / Яндекс, тогда используйте Документы Google или Яндекс.Диск. Доблявть файлы или целые папки так же просто, как перетащить их в список документов, если вы используете браузер Chrome.

Что резервировать (в дополнение к очевидному)

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

Резервные копии браузера

Не теряйте тщательно культивируемые закладки браузера или избранное. Основные браузеры , такие как Mozilla Firefox и Google Chrome имеют системы встроенного резервного копирования, если вы подключаете аккаунт Mozilla или Google. Браузеры будут создавать резервные копии данных, таких как закладки, история, надстройки и даже открытые вкладки, в некоторых случаях – синхронизировать их между браузерами и компьютерами. В Firefox введите about:preferences#sync в адресной строке; в Chrome введите chrome://settings/syncSetup.

Электронная почта

Если вы используете систему электронной почты на основе Интернета, такую как Gmail или Outlook.com, это может показаться не большой проблемой – вся ваша почта находится в облаке, контролируемой крупными компаниями, что может пойти не так? Но, даже у крупных компаний случаются перебои. Поэтому, если все ваши сообщения критически важны, время от времени создавайте резервную копию.

Для Gmail вы можете использовать Google Takeout. Outlook.com не позволяет экспортировать, но сторонний программный продукт, такой как eM Client (бесплатный для домашнего использования), может получить доступ к Gmail и Outlook.com и запустить автоматическое резервное копирование.

Использование клиентского программного обеспечения, такого как Outlook, с Microsoft Office 365, является предпочтением многих, но ситуация с резервным копированием намного сложнее, так как для этого требуется создать резервную копию файла, называемого PST (Personal Storage Table). Microsoft предоставляет полные инструкции по этому поводу.

Лучшее решение из всех: использовать Outlook с сервисом, который хранит вашу электронную почту на сервере – это может быть что-то вроде собственного Outlook.com или Gmail с рабочей учетной записью через Exchange Server или IMAP. Затем вы получите ваше сообщение в облаке, но также и в OST (автономном файле данных Outlook), который снова можно создать отдельно.

Драйверы

Если у вас есть аппаратная периферия, подключенная к вашему компьютеру, у вас есть драйверы – программное обеспечение, которое позволяет вашему ПК общаться с видеокартами, принтерами, сканерами и тому подобным. Если вы еще не создали образ диска, по крайней мере, сохраните ваши текущие драйверы с помощью инструмента, такого как Double Driver.

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

Социальные сети

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

Прочитайте, как загрузить ваши данные Facebook. Твиттер похож, но менее сложен: в вашем браузере на рабочем столе зайдите в настройки вашей учетной записи. Прокрутите вниз и нажмите «Запросить свой архив». Вы получите по электронной почте ссылку с полным файлом всех ваших твитов и загруженных фотографий.

Пожалуй, нет другой такой темы, которая бы была столь заезжена — о резервном копировании не писал только ленивый. Она с завидной постоянностью поднимается во всех технических обсуждениях, про нее слагают анекдоты. Но, парадокс! Как только дело доходит до восстановления, то выясняются очень неприглядные вещи, начиная от отсутствия резервной копии и заканчивая тем, что копия вроде бы как есть, только вот… А работа стоит, предприятие несет убытки… Поэтому сегодня мы предлагаем вам поговорить о резервном копировании: что это вообще такое и как правильно организовать этот процесс, чтобы потом можно было спать спокойно.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Основной причиной написания данной статьи стал пожар в датацентре крупнейшего европейского хостинг-провайдера OVH. В ночь на 10 марта 2021 года огонь полностью уничтожил датацентр SBG2, частично выгорел SBG1, еще два датацентра не пострадали, но были отключены. Список пострадавших крайне широк: это правительственные ресурсы Франции, Великобритании, Польши, крупные европейские медиа-ресурсы, промышленные предприятия, спортивные клубы, разработчики ПО и т.д. и т.п. Последствия тоже различные: так, например, шахматный интернет-сервис Lichess.org отделался «легким испугом».

В Twitter-аккаунте шахматного сайта Lichess.org сообщается, что в пожаре сгорело несколько серверов Lichess. Впрочем, благодаря усердию сисадмина, который позаботился о резервном копировании, потери данных удалось минимизировать — утрачена история шахматных задач только за последние 24 часа.

А вот некоторым повезло меньше, разработчик игр Rust потерял все свои данные:

«Мы подтверждаем полную потерю серверов из-за пожара в центре обработки данных OVH. Мы изучаем возможность замены оборудования. Восстановление данных невозможно», — сообщение Rust в Twitter.

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

Резервная копия, архив и синхронизация — в чем разница?

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

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

В чем разница? В отличие от резервной копии, архив — это рабочая копия данных, в правильности и достоверности которых мы уверены. Скажем в бухгалтерском учете такой операцией может являться закрытие месяца, квартала, полугодия, года. После чего мы можем быть уверены, что данные в базе соответствуют реальному положению дел и ее можно отправлять в архив. Таким образом копия сделанная 31 марта не будет являться архивом за квартал, так как все необходимые регламентные операции еще не выполнены и в достоверности данных мы не уверены.

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

Значит ли это, что не синхронизацию использовать не следует? Отнюдь, просто нужно понимать, что это не способ резервного копирования, а один из методов повышения отказоустойчивости, как RAID. В случае аппаратного отказа основного узла у нас на руках будет практически на 100% идентичная копия, которая позволит быстро восстановить работу сервиса. Но от ошибочных действий с данными или атаки вируса-шифровальщика синхронизация нас не спасет.

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

Как часто и в каком объеме копировать?

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

Резервное копирование баз данных исполнитель производит не реже одного раза в день. Резервные копии хранятся не менее трех лет.

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

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

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

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

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

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

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

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

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

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

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

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

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

Это как раз та область, где простота только приветствуется, чем сложнее схема — тем больше ошибок может в ней возникнуть и тем сложнее ее контролировать. Набор простых заданий хорош тем, что даже если сломается одно из них — остальные будут продолжать работать. Ну и не забывайте про ресурсы. Вместо одного общего хранилища выделите под каждый набор данных собственное: отдельные диски, разделы, виртуальные или iSCSI-диски, дисковые лимиты в конце концов.

Что именно копировать?

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

Возьмем следующий пример: у нас есть виртуальная машина с некоторым сервисов внутри, скажем сервером СУБД. Какие варианты резервного копирования нам доступны? Прежде всего копирование самой виртуальной машины. Вариант хороший, многие на этом и останавливаются, забывая о сценариях, когда восстановить виртуалку будет невозможно. Аптайм серверных систем достаточно велик, а многие ошибки проявляют себя только после перезагрузки, таким образом можно получить копии, которые сняты с работоспособной машины, но загрузиться они не смогут. Да, в большинстве случаев ОС можно восстановить, но это дополнительные затраты времени в и без того критической ситуации, одним словом пожар во время наводнения. Да и все может оказаться гораздо проще — нет запасного гипервизора.

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

Но бывают и иные ситуации, когда нам нужно восстановить одну единственную базу, либо нет возможности поднять новый экземпляр СУБД, но есть уже существующий, в который вполне можно загрузить нужные базы. Для этого нужно иметь дампы баз данных по отдельности. Да, их можно выгрузить располагая полным дампом или образом ВМ, но это снова дополнительное время и необходимость в дополнительных ресурсах.

И наконец то, о чем многие забывают. Настройки! Мы многократно были свидетелями возникновения аварийных ситуаций только от того, что администратор пошел вносить изменения в настройки работающего сервиса, не сделав их копии. А теперь представим, что у вас были достаточно сложные персонализированные настройки для СУБД или веб-сервера, без них восстановить работоспособность сервиса в полной мере не удастся, даже при наличии всех остальных данных.

Таким образом правильная организация резервного копирования предполагает наличие копий данных на разных уровнях абстракции: виртуальная машина, дамп сервера БД, каждая БД отдельно и т.д и т.п. А также обязательное копирование настроек, для этих целей неплохо подходят системы контроля версий (git и т.п.), что позволяет не только иметь их копию, но и отслеживать всю историю изменений, с возможностью быстрого отката.

Где и как хранить копии?

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

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

Все должно следовать той же логике анализа угроз и способов им противодействовать. Резервные копии должны не только храниться в надежном месте, но и быть доступны в случае необходимости. Что толку в копии виртуальной машины на удаленном хостинге если копироваться она оттуда будет несколько часов, а восстановить одну из нескольких СУБД нужно здесь и сейчас.

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

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

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

Теперь о форматах. Копию для непосредственного восстановления данных лучше всего хранить в родном формате защищаемого приложения, желательно без сжатия, так как наша цель не экономия хранилища, а максимально быстрое восстановление. Для баз данных это может быть дамп средствами самой СУБД. Но могут быть ситуации, когда рабочего экземпляра СУБД нет, а данные восстановить надо. Это важно для приложений, которые могут использовать различные СУБД и платформы для работы. Скажем вместо аварийного сервера с PostgreSQL на Linux у вас есть работающий MS SQL на Windows. Для этих целей нужно иметь выгрузку данных в универсальный формат для восстановления на любой платформе, это может быть как родной формат приложения, так и некоторый универсальный, скажем XML.

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

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

Почему? Хороший пример — пожар в датацентре OVH, с которого мы начали статью. Также можно вспомнить «споры хозяйствующих субъектов», которые привели практически к полной остановке работы хостера Айхор с физическим отключением и вывозом серверов. Также следует иметь ввиду техногенные аварии и природные катаклизмы, которые могут привести к проблемам во всем регионе.

Промежуточный итог

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

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

Другой пример: архив 1С: Предприятия хранится в формате дампов СУБД, а не выгрузки самой 1С. В итоге при необходимости развернуть архивную базу локально или на сервере с иной системой управления базами данных администратору сначала потребуется развернуть дамп, подключить базу и сделать из нее выгрузку в формат 1С:Предприятия.

Зеркальная ошибка — хранение резервных копий только в формате выгрузки 1С (DT-файлы), хотя сам разработчик предупреждает, что данный формат не предназначен для резервного копирования, так как ряд ошибок могут не препятствовать выгрузке, только вот загрузить такую копию уже не удастся. Тоже самое можно отнести и копиям виртуальных машин.

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

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

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

Резервные копии нужно проверять

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

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

Еще один важный аспект регулярных проверок — это получение реальных данных о времени и ресурсах необходимых для данной процедуры. Поэтому нужно логировать не только неудачные попытки восстановления, но и успешные, с обязательным регулярным анализом. Именно анализ времени восстановления позволил одному из наших заказчиков своевременно выявить деградацию RAID массива в недорогом NAS, когда резко увеличилось время чтения с устройства хранения, хотя сам NAS продолжал считать, что у него все нормально.

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

А как насчет плана восстановления?

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

Что такое план восстановления? Это детально и максимально подробно описанная процедура восстановления рабочей копии данных из резервной. Своего рода пошаговая инструкция, дословно выполнив которую любой специалист достаточного уровня сможет произвести восстановление данных. При этом внести в нее нужно всё, в том числе и банальные, очевидные на первый взгляд, вещи. Потому что в условиях стресса это может вылететь из головы, а еще, то что «очевидно» для вас, не всегда является очевидным для ваших коллег.

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

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

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

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

Выводы

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

• Главная

• Блог

• Инфраструктура

• Гайд по резервному копированию: виды, решения и ПО

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

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

Почему нужно защищать данные

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

• Выход из строя физических носителей. «Железо» не вечно: любые накопители могут сломаться в самый неподходящий момент, и в результате ценные данные будут потеряны.
• Сбои ПО. Они могут приводить к тому, что данные просто исчезнут (файлы повредятся без возможности восстановления). И если не было настроено резервное копирование, изменения последних дней, недель и даже месяцев будут утрачены.
• Кибератаки. Наибольшую уязвимость представляют данные, к которым был открыт какой-либо доступ через сеть. Такие файлы можно легко повредить, удалить или, еще хуже, зашифровать с целью получения выкупа. Последнее актуально прежде всего для крупного и среднего бизнеса.

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

Виды резервного копирования данных

Существует два основных типа резервных копий: они могут создаваться в виде файлов или образов. Выбор того или иного решения зависит прежде всего от типа данных, с которыми работает компания. Исходя из этого подбирается также и ПО для резервного копирования (программы будут рассмотрены далее).

Методы резервирования

Методов резервного копирования данных насчитывается пять:

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

Какой метод выбрать, решают в зависимости от объема базы (или баз) данных, аппаратного обеспечения и задач. Однако успешность создания бэкапов зависит и от других факторов. Например, от правильного планирования, что мы и рассмотрим далее.

Планирование бэкапов

Это необходимо для минимизации факторов риска, к которым относятся неполадки, сбои, ошибки, кибератаки. Грамотно составленный план обеспечит восстановление данных с минимальными (а то и нулевыми) потерями. При планировании учитываются:

• типы данных (например, БД, образы, папки или email);
• временные затраты на создание бэкапа (этот параметр называется RTO);
• время между точками восстановления (RPO), на основании которого определяется периодичность создания бэкапов;
• методы создания бэкапа (о них выше);
• места для хранения бэкапов (физические или облачные хранилища, типы устройств и т. д.);
• политики хранения резервных копий.

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

Политики резервирования

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

• 3-2-1. «3» здесь означает три обязательных резервных копии, «2» — типы носителей (часто это диск + облачное хранилище), а «1» — обязательное хранение одной из копий за пределами физического сервера (то же облако, как пример).
• GFS или Grandfather-Father-Son. Пример: ежемесячная, еженедельная и ежедневная копии базы данных.
• TOH или Tower of Hanoi. Эта политика используется при нехватке места в хранилище или когда для создания бэкапов задействуют разные типы носителей. Суть политики TOH заключается в хранении бэкапов на разных носителях, чтобы копии восстанавливались без потерь, если какое-то из хранилищ откажет.

Решения резервирования

• Bare-metal. Нужное ПО ставится непосредственно на железо, минуя ОС. Это дает преимущества в виде возможности восстановления любых данных и преобразования физических образов в виртуальные.
• Single-pass. Резервирование и восстановление за один проход, что подойдет, если создаются бэкапы одного типа (только файлы или только образы). В противном случае для каждого типа бэкапа придется выполнять все операции заново.
• Real-Time Backup (или CDP, или Continuous Backup). Копии создаются в автоматическом режиме при каждом изменении исходных данных. Разумеется, при этом нужно производительное аппаратное обеспечение, потому что нагрузка на память и процессорные мощности серьезная.
• Remote Replication. Это решение используется, когда выполняется работа с несколькими резервными копиями и на нескольких ресурсах.

Выбор программ

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

• Acronis True Image. Поддерживаются версии для каждой ОС, при этом Acronis демонстрирует повышенную скорость копирования и восстановления копий. Однако есть и минус: не поддерживается контейнеризация в облачных средах. Зато Acronis работает с любыми типами данных, позволяя шифровать их.
• Veeam Backup. Поддерживает разнообразные сетевые протоколы и подойдет для тех, кто профессионально работает с базами данных. Обеспечивает переключение резервных мощностей, имеет функции полного и выборочного копирования. При этом программа бесплатна.
• Backup4all. Здесь заявлена полная поддержка облачных сервисов, также есть гибкая система фильтров и возможность дробления резервных копий. Из других плюсов выделим «умную» обработку, при которой исключается двойное сжатие файлов, уже находящихся в архивах, что увеличивает скорость создания и восстановления копий. Полная версия Backup4all позволяет использовать облачные мощности Dropbox и Drive.Google. Недостаток у этого решения только один: могут некорректно преобразовываться кириллические символы в названиях файлов.
• Iperius Backup. Поддерживает большинство облачных сервисов, обеспечивает повышенную скорость обработки больших данных. Также есть защита от случайного завершения работы, что реализуется через функцию запуска программы в виде службы.
• ApBackUP. Недорогая российская программа с расширенным функционалом: поддерживается создание правил для выполнения бэкапов по инкрементным и дифференциальному методам, доступны различные варианты хранения копий. А еще ApBackUP поддерживает сторонние архиваторы, так что архивирование с помощью этой утилиты становится мощнее.

Среды резервирования

Для резервирования задействуется три типа хранилищ: диски, ленты и облако.

• Диски. Надежные, быстрые, однако дороже остальных носителей, особенно если речь об SSD. К тому же SSD имеют ограничения по циклам записи/перезаписи и существенно ограничены по емкости. Другой тип дисков, часто выбираемый для бэкапов — HDD, которые отличаются большими объемами и более низкой стоимостью, в сравнении с SSD.
• Ленты. Ленточные накопители работают по тому же принципу, что и обычные магнитные ленты, и до сих пор популярны для целей резервного копирования. Они дешевые и хранят огромные объемы информации. Но, в отличие от дисков, ленты не поддерживают произвольный доступ к данным — только последовательный, поэтому они намного медленнее.
• Облако. Подойдет, если компания использует политику 3-2-1. Из минусов отметим зависимость от облачного провайдера и снижение конфиденциальности информации.

Восстановление данных

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

Восстановление данных из резервных копий обычно выполняется с использованием тех же утилит, при помощи которых создаются бэкапы. Если вы работаете с базами данных, то такие решения, как Oracle, Postgres, SQL Server имеют собственные инструменты для создания резервных копий и для восстановления.

Катастрофоустойчивость

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

Репликация — это тоже копирование, принцип работы которого состоит в том, что создаются точные виртуальные копии объектов, которые затем постоянно синхронизируются с исходными данными. Но реплики не помогут в случае возникновения логических ошибок и изменения внутренней структуры данных. Поэтому резервное копирование — необходимая процедура для безопасности данных. А для катастрофоустойчивости резервные копии должны храниться на удалении от ЦОД компании.

Check the downloadable pdf user guide for a full desciption of all the available tools and backup features.