Резервное копирование это: Система резервного копирования / Habr – Методика резервного копирования в быту для экономных и осторожных

Содержание

Резервное копирование - это... Что такое Резервное копирование?

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

Резервное копирование (англ. backup) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Наименование операций

  • Резервное копирование данных (Резервное дублирование данных) — процесс создания копии данных
  • Восстановление данных — процесс восстановления в оригинальном месте

Цель

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

Кроме этого решаются смежные проблемы:

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

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

Question book-4.svg В этом разделе не хватает ссылок на источники информации. Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.
Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники.
Эта отметка установлена 2 июля 2011.
Полное резервирование (Full backup)
Полное резервирование обычно затрагивает всю вашу систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервирование подразумевает полное резервирование. Первое еженедельное резервирование должно быть полным резервированием, обычно выполняемым по пятницам или в течение выходных, в течение которого копируются все желаемые файлы. Последующие резервирования, выполняемые с понедельника по четверг до следующего полного резервирования, могут быть добавочными или дифференциальными, главным образом для того, чтобы сохранить время и место на носителе. Полное резервирование следует проводить, по крайней мере, еженедельно.
Дифференциальное резервирование (Differential backup)
При разностном (дифференциальном) резервировании каждый файл, который был изменен с момента последнего полного резервирования, копируется каждый раз заново. Дифференциальное резервирование ускоряет процесс восстановления. Все, что вам необходимо, это последняя полная и последняя дифференциальная резервная копия. Популярность дифференциального резервирования растет, так как все копии файлов делаются в определенные моменты времени, что, например, очень важно при заражении вирусами.
Инкрементное резервирование (Incremental backup)
При добавочном («инкрементальном») резервировании происходит копирование только тех файлов, которые были изменены с тех пор, как в последний раз выполнялось полное или добавочное резервное копирование. Последующее добавочное резервирование добавляет только файлы, которые были изменены с момента предыдущего добавочного резервирования. В среднем, добавочное резервирование занимает меньше времени, так как копируется меньшее количество файлов. Однако, процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервирования, плюс данные всех последующих добавочных резервирований. При этом, в отличие от дифференциального резервирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Резервирование клонированием
Клонирование позволяет скопировать целый раздел или носитель (устройство) со всеми файлами и директориями в другой раздел или на другой носитель. Если раздел является загрузочным, то клонированный раздел тоже будет загрузочным[1].
Резервирование в виде образа
Образ — точная копия всего раздела или носителя (устройства), хранящаяся в одном файле[2].
Резервное копирование в режиме реального времени
Резервное копирование в режиме реального времени позволяет создавать копии файлов, директорий и томов, не прерывая работу, без перезагрузки компьютера.
[3]

Схемы ротации

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

Одноразовое копирование

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

Простая ротация

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

«Дед, отец, сын»

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

«Ханойская башня»

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

«10 наборов»

Данная схема рассчитана на десять наборов носителей. Период из сорока недель делится на десять циклов. В течение цикла за каждым набором закреплен один день недели. По прошествии четырехнедельного цикла номер набора сдвигается на один день. Иными словами, если в первом цикле за понедельник отвечал набор номер 1, а за вторник — номер 2, то во втором цикле за понедельник отвечает набор номер 2, а за вторник — номер 3. Такая схема позволяет равномерно распределить нагрузку, а следовательно, и износ между всеми носителями.

Схемы «Ханойская башня»[источник не указан 349 дней] и «10 наборов» используются нечасто, так как многие системы резервирования их не поддерживают.

Хранение резервной копии

Методы борьбы с утерей информации

Утеря информации бывает по разным причинам.

Эксплуатационные поломки носителей информации

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

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

  • RAID 1, обеспечивающий восстановление самой свежей информации. Файлы, расположенные на сервере с RAID, более защищены от поломок, чем хранящиеся на локальной машине;
  • Ручное или автоматическое копирование на другой носитель. Для этого может использоваться система контроля версий, специализированная программа резервного копирования или подручные средства наподобие периодически запускаемого cmd-файла.

Стихийные и техногенные бедствия

Описание: шторм, землетрясение, кража, пожар, прорыв водопровода — всё это приводит к потере всех носителей данных, расположенных на определённой территории.

Борьба: единственный способ защиты от стихийных бедствий — держать часть резервных копий в другом помещении.

Вредоносные программы

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

Борьба:

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

Человеческий фактор

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

Борьба:

  • Тщательно расставить права на все ресурсы, чтобы другие пользователи не могли модифицировать чужие файлы. Исключение делается для системного администратора, который должен обладать всеми правами на всё, чтобы быть способным исправить ошибки пользователей, программ и т. д.
  • Построить работающую систему резервного копирования — то есть, систему, которой люди реально пользуются и которая достаточно устойчива к ошибкам оператора. Если пользователь не пользуется системой резервного копирования, вся ответственность за сохранность ложится на него.
  • Хранить версии достаточной давности, чтобы при обнаружении испорченных данных файл можно было восстановить.
  • Перед переустановкой ОС следует обязательно копировать всё содержимое раздела, на которой будет установлена ОС, на сервер, на другой раздел или на CD / DVD.
  • Оперативно обновлять ПО, которое заподозрено в потере данных.

См. также

Ссылки

Примечания

Резервная копия - это... Что такое Резервная копия?

Не следует путать с термином «архивация».

Резервное копирование (англ. backup) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном месте их расположения в случае их повреждения или разрушения.

Цель

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

Кроме этого решаются смежные проблемы:

  • Дублирование данных
  • Передача данных и работа с общими документами

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

Простота в эксплуатации — автоматизация (по возможности минимизировать участие человека: как пользователя, так и администратора).

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

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

Полное резервирование Full Backup

Дифференциальное резервирование Differential Backup

Добавочное резервирование Incremental Backup

Пофайловый метод

Блочное инкрементальное копирование Block Level Incremental

Схемы ротации

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

  • Одноразовое копирование;
  • Простая ротация;
  • «Дед, отец, сын»;
  • «Ханойская башня»;
  • «10 наборов».

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

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

Хранение резервной копии

Методы борьбы с утерей информации

Физическая порча носителей информации (жёстких дисков, дискет, CD/DVD)

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

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

Эта причина не самая распространенная, так как современные жёсткие диски редко выходят из строя.

Современный жёсткий диск работает до отказа порядка трех лет — в режиме постоянно включенного компьютера (сервера). Тонкий момент: если организован RAID 1 на двух одинаковых жёстких дисках, введенных в эксплуатацию одновременно, то выходить из строя они будут примерно в одно и то же время!

Уничтожение (или порча) информации из-за компьютерных вирусов

Борьба — установка антивирусных программ на сервер и рабочие станции. Антивирусы будут постоянно обновляться из одной общей папки: первая копия антивируса получает обновления прямо из Интернета, а другие копии настроены на папку, куда первая загружает обновления), или нужно грамотно настроить proxy, чтобы обновления кешировались (это всё меры для уменьшения трафика).

Случайное (преднамеренное) удаление (изменение) информации другого пользователя

Борьба:

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

Удаление информации из-за несогласованности действий

Один человек записал куда-то свои файлы, а другой непреднамеренно удалил. Борьба:

  • пользователи или хранят ценную информацию в местах известных (указанных пользователем) системному администратору. Если пользователь сохраняет информацию в любых других местах — вся ответственность за сохранность ложится на пользователя;
  • при этом системный администратор не удалит без ведома пользователя никакие «непонятные» папки с компьютера пользователя.
  • перед переустановкой Операционной системы следует обязательно копировать всё содержимое раздела (на которой будет установлена ОС) на сервер, на другой раздел или на CD / DVD.

Сильное дублирование информации (одновременное существование множества копий одного и того же документа)

Каждый пользователь только сам знает, какие версии документов последние и самые нужные. Дублирование должно быть незаметным для пользователей (то есть для пользователей «видна» только одна копия каждого документа).

См. также

Ссылки

Wikimedia Foundation. 2010.

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

Дата публикации: 21 ноября 2018 г.

* * *

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

Full Backup: ПОЛНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ


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

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

Преимущества Full Backup:

  • быстрое восстановление данных
  • простое управление
  • все данные содержаться в одной резервной копии

Недостатки Full Backup:

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

* * *

Differential Backup: ДИФФЕРЕНЦИАЛЬНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ


Дифференциальное резервное копирование применяется в системах

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

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

Преимущества Differential Backup:

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

Недостатки Differential Backup:

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

* * *

Incremental Backup: ИНКРЕМЕНТНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ


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

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

Преимущества Incremental Backup:

  • высокая скорость резервного копирования (копируются только блоки изменённых данных)
  • меньше места для хранения (по сравнению с полным)
  • большее количество точек восстановления

Недостатки Incremental Backup:

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

* * *

Reverse Incremental Backup: ОБРАТНОЕ ИНКРЕМЕНТНОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ


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

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

Преимущества Reverse Incremental Backup:

  • быстрое восстановление (для последних копий)
  • более высокая безопасность данных
  • более гибкое управление объемом хранилища (buckup repository). При не хватке места, без последствий можно удалить старые версии резервных копий
  • низкая загрузка сети (как для обычного инкрементного РК)

Недостатки Reverse Incremental Backup:

  • более высокие требования к серверу резервного копирования
  • больше времени для восстановления старых копий

* * *

Synthetic Full Backup: СИНТЕТИЧЕСКОЕ РЕЗЕРВНОЕ КОПИРОВАНИЕ


Синтетическое резервное копирование применяется в системах

Синтетическая резервная копия имеет много общего с обратным инкрементным типом резервного копирования. Различия заключается в том, что для создания новой полной резервной копии используются ранее созданные full и Incremental Backup. Синтетическое резервное копирование, как и остальные способы, начинается с создания полной резервной копии, за которой следует серия инкрементных резервных копий. В заданный момент существующая полная резервная копия и инкременты объединяются (синтезируются) в новую полную резервную копии, эта новая копия станет исходной для создания следующих инкрементов и т.д. Синтетический тип резервного копирования обладает такими же преимуществами как full backup, но при этом решает его недостатки, меньше нагружает сеть и экономит пространство для хранения бэкапа.

Преимущества Synthetic Full Backup:

  • высокая скорость резервного копирования и восстановления
  • гибкое управление данными
  • низкая загрузка сети (для получения инкрементных РК)

Недостатки Synthetic Full Backup:

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

* * *

Вывод

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

 

Назначение, обзор методов и технологий / Southbridge corporate blog / Habr

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

—Жан Брюлер

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

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

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

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

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

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

— Есть два вида системных администраторов, те кто не делает резервные копии, и те, кто УЖЕ делает.
— На самом деле три вида: есть еще те, кто проверяет, что резервные копии можно восстановить.

—Неизвестный

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

Под форматом хранения следует понимать следующее:

  • Если есть зависимость от физического способа хранения — меняем физический способ.
  • Если есть зависимость от логического способа хранения — меняем логический способ.

Для достижения максимального эффекта правила 3-2-1 рекомендуется менять формат хранения обоими способами.

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

Не стоит путать горячие и холодные копии с online и offline копиями, которые подразумевают физическую изоляцию данных, и по сути, являются другим признаком классификации способов резервного копирования. Так offline копия — не подключенная непосредственно к системе, где ее надо восстановить, — может быть как горячей, так и холодной (с точки зрения готовности к восстановлению). Online копия может быть доступна непосредственно там, где ее надо восстанавливать, и чаще всего является горячей, но бывают и холодные.

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

Разностные инкрементальные копии — попытка сэкономить размер пространства для хранения резервных копий. Таким образом в резервную копию пишутся только измененные данные с прошлой резервной копии.

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

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

Quis custodiet ipsos custodes?

(Кто устережет самих сторожей? — лат.)

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

  • Целостность исходных данных была нарушена.
  • Хранилище с резервными копиями повреждено.
  • Восстановление работает весьма неспешно, нельзя пользоваться данными, которые частично восстановлены.

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

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

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

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

Знает толк в пряностях не тот, кто добавляет их в каждое блюдо, но тот, кто никогда не добавит в него ничего лишнего.

—В. Синявский

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

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

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

  • dd, знакомая ветеранам системного администрирования, сюда же относятся схожие программы (та же dd_rescue, например).
  • Встроенные в некоторые файловые системы обслуживающие программы (утилиты), создающие слепок (dump) файловой системы.
  • Всеядные утилиты; например, partclone.
  • Собственные, зачастую собственнические, решения; например, NortonGhost и более поздние.

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

  • Rsync, универсальную программу и протокол для синхронизации состояния файловых систем.
  • Встроенные средства для архивации (ZFS).
  • Сторонние средства для архивации; самый популярный представитель — tar. Есть и другие, например, dar — замена tar с ориентацией на современные системы.

Отдельно стоит упомянуть о программных средствах обеспечения консистентности данных при создании резервных копий. Чаще всего применяют следующие варианты:
  • Монтирование файловой системы в режим только чтение (ReadOnly), или замораживание файловой системы (freeze) — метод применим ограниченно.
  • Создание слепков состояния файловой систем или блочного устройства (LVM, ZFS).
  • Применение сторонних средств для организации слепков, даже в тех случаях, когда предыдущие пункты не могут быть обеспечены по каким-либо причинам (программы вида hotcopy).
  • Техника копирования при изменении (CopyOnWrite), однако она чаще всего привязана к используемой ФС (BTRFS, ZFS).

12 типичных ошибок при бэкапе баз данных / Habr


Изначально эта статья задумывалась только для разработчиков и администраторов СУБД Firebird, но после общения с администраторами других БД выяснилось, что большинство ошибок общие, и на очень похожие грабли наступают буквально все. Если Вы можете что-то добавить к этому списку (пусть даже специфическое для конкретной СУБД), пишите в личную почту или в комментариях.
In English: 12 Common Mistakes while Backing Up Databases

Наша компания занимается инструментами восстановления, резервного копирования, оптимизации и поддержкой СУБД (в основном Firebird, но есть и MSSQL, PostgreSQL, InterBase и др.) и, как результат многочисленных аудитов и ремонтов, накопила коллекцию ошибок, связанных с резервным копированием. Все пункты ниже изложены по мотивам реальных случаев с повреждением баз, потерей и повреждением бэкапов, дисков, сбоями серверов, и прочих «радостей» администраторов БД.

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

Итак, приступим.

1. Удаление предыдущей копии бэкапа до того, как будет создана новая копия бэкапа
Чаще всего эту ошибку совершают новички, которые не понимают, что основная цель существования резервной копии БД – обеспечить минимальный простой информационной системы (важной частью которой является БД), а не просто создание копии БД.
В результате, с момента удаления последнего бэкапа до создания нового, система находится в незащищенном состоянии, потому что в этот период у базы данных нет ни одной резервной копии. Так как бэкап может создаваться достаточно долго, то это идеальное время для срабатывания закона Мерфи. Особенно хорошо этот подход работает в связке с пунктом 7 (см. ниже).
Рекомендация: не удаляйте предыдущий бэкап до того момента, как создан новый! (и не делайте новый бэкап в уже существующий файл)

2. Перезапись существующей базы данных при восстановлении из бэкапа
Эту ошибку совершают реже, но вот результаты могут быть гораздо печальнее. Если бэкап не проверялся и был поврежден (см. пункт 6), то в результате перезаписи у вас не будет ни предыдущей копии базы, ни валидного бэкапа.
Обычно это безобразие случается в пятницу вечером, в момент дерготни, неразберихи и противоречивых указаний со стороны начальства. Немного отрицательного везения и томные выходные в серверной обеспечены.
У Firebird есть некая защита от этой ошибки – создание рестора из бэкапа с помощью утилиты gbak с дефолтным ключом –create не сработает в случае, если указанное имя файла указывает на существующую БД. К сожалению, есть и обход этой защиты – переключатель –rep, который позволяет-таки переписать существующий файл.
Рекомендации: никогда не перезаписывайте файл боевой БД, не получив письменного указания руководства и, желательно, не получив предложения о новой работе.

3. Использование одношагового бэкапа-рестора, без создания промежуточного файла бэкапа
Стандартные потоки ввода-вывода позволяют провернуть с многими СУБД (с Firebird в том числе) интересный трюк: выполнять потоковый бэкап с немедленным восстановлением БД из него. В результате не создается промежуточный файл бэкапа. Это удобно для проведения регламентных работ и запуска проверочного восстановления (при наличии другой резервной копии), но ни в коем случае не надо использовать это для автоматического бэкапа!
Если в процессе такого бэкап-рестора произойдет серьёзный сбой диска, например, то может повредиться исходная база данных, а новая еще не будет создана. Конечно, если п.1 соблюдается, и есть копия БД от предыдущей попытки, то произойдет только потеря данных, которые были созданы или изменены в БД с момента создания ее копии.
Рекомендации: не используйте одношаговый бэкап-рестор в автоматическом режиме, а в ручном всегда проверяйте наличие достаточно свежей копии.

4. Хранение бэкапа и базы данных на одном и том же физическом устройстве
Тут многие могут посмеяться, что советы мы какие-то детские даем – это же азбука системного администрирования. Так-то оно так, но в связи с распространением виртуальных сред и БД, и диск могут находиться на одной СХД. А она обязательно сломается в самый неподходящий для бизнеса момент. Плюс, все еще существуют люди, которые верят в то, что если они используют RAID (от 1 и выше), то с их данными вообще ничего не может случиться. Еще есть люди, которые верят в сверхнадежность «брендового» железа, но это особый случай.
Рекомендации: не храните бэкап и БД на одном и том же физическом устройстве, каким бы надежным оно не казалась.

5. Отсутствие проверки успешного окончания бэкапа
Вот это довольно частая ошибка и администраторов, и руководителей ИТ подразделений. Если результат бэкапа не проверять, то можно бэкап не делать вообще — результат в общем тот же. Обязательно нужны нотификации по email об успешном бэкапе, а еще лучше и по СМС. Причем, отсутствие нотификации это признак проблемы!
А причем тут руководители, спросит внимательный читатель, дочитавший до этого места? А притом, что администратор обычно бэкап настроит, но вот нотификации ему проверять лень, тем более что лежат они у него в отдельной папочке, и поэтому руководителю ИТ-отдела надо периодически запрашивать дополнительный отчет о состоянии всех бэкапов. Это к вопросу, кого наказывать, если бэкапы вроде есть, но в нужный момент их не оказалось 🙂
! А при комбинировании с пунктом 2 получаем отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты автоматизации бэкапов, которые умеют отслеживать успешные и неуспешные бэкапы, сообщать пользователям о проблемах, и имеют обзорные средства контроля (особенно актуально, когда нужно контролировать десятки и сотни бэкапов на разных серверах).

6. Отсутствие валидации бэкапов
То, что бэкапы куда-то кладутся, не означает, что они оттуда могут быть прочитаны.
Поэтому обязательна периодическая верификация создаваемых бэкапов, чтобы быть уверенным, что создаваемые бэкапы не повреждены, не были скопированы в /dev/null
Рекомендации: никому не доверять, даже себе. Всех надо проверять.

7. Отсутствие health check базы данных при использовании неверифицированных бэкапов
Обычно СУБД имеют несколько видов бэкапа – дампы, просто бэкапы и т.д. Не вдаваясь в конкретику, можно выделить 2 категории – верифицированные и неверифицированные бэкапы. У Firebird это gbak и nbackup.
Gbak читает всю БД на уровне записей для создания файла бэкапа, и создает БД путем вставки записей в новую БД, и таким образом верифицирует и бэкап (есть варианты, как ошибки могут просочиться в отресторенную копию, но это уже другой вид факапа администратора БД, связанный с неверной миграцией), и саму базы данных (если она может быть прочитана от начала до конца, то с большой долей вероятности она не повреждена).
Nbackup (он же инкрементальный бэкап) – временно блокирует основной файл БД на запись (в консистентном состоянии), и позволяет быстро скопировать файл базы данных (полностью или частично/инкрементально).
Для больших БД Firebird (более 500Гб), предпочтительно делать nbackup, чтобы не тормозить работу пользователей, но при этом нужно проверять БД, ведь созданные неверифицированные бэкапы – это страничные копии БД, и если ошибка гнездится на уровне записей (такое случается из-за сбоя RAM) или на логическом уровне, то неверифицированный бэкап будет ее содержать так же, как и оригинальная БД.
Для этого нужно использовать онлайн-валидацию исходной базы данных (в Firebird начиная с версии 2.5.4 доступна онлайн-валидация при помощи gfix, а наш инструмент FBDataGuard поддерживает онлайн-проверку БД для версий 1.5-2.5).
Также, в дополнение к неверифицированному бэкапу желательно периодически (раз в неделю, например) делать верифицированный бэкап.
Для других СУБД необходимо использовать соответствующие средства и комбинации проверок.

8. Отсутствие контроля за свободным местом для бэкапа
В общем-то, это классическая ошибка — при недостатке места бэкап занимает все свободное место и аварийно завершается. При размещении бэкапа на одном диске вместе с БД может привести к остановке работы с БД, при размещении на системном диске – к поломке системы.
В комбинации с пунктом 4 в лучшем случае получим остановку работы системы, потому что базе данных тоже нужно свободное место, а оно кончилось из-за бэкапа.
А в комбинации с пунктами 5 и 2 опять получаем в результате отсутствие и базы, и бэкапа.
Рекомендации: использовать инструменты для бэкапа, которые делают прогноз размера бэкапа и предупреждают о возможной нехватке места.

9. Отсутствие контроля времени продолжительности бэкапа
Буквально полгода назад бэкап длился 40 минут, и вдруг стал 3 часа – почему? Возможно, вырос размер БД, а может быть, выпал диск из RAID-массива, отчего скорость записи резко деградировала, и все ваши бэкапы вот-вот покинут этот бренный мир. А может быть, добрый коллега одновременно включил еще одну систему резервного копирования (кстати, в Firebird можно запустить несколько бэкапов сразу, только не очень понятно, зачем это может быть нужно).
Если не контролировать время исполнения бэкапа, то можно проглядеть возникшую проблему и упустить шанс исправить ее до того, как она станет большой.
Также, в случае, если система резервного копирования не отслеживает состояния заданий, а запускает их просто по графику, легко можно попасть на «утренний троллейбус» — это когда новый бэкап может начаться в момент, пока предыдущий еще не закончился.
Рекомендации: использовать средства контроля продолжительности процесса бэкапа.

10. Исполнение бэкапа БД во время применения апдейтов ОС
Очень частая проблема, особенно в комбинации с п.9 и включенными автоматическими апдейтами Windows (которые по умолчанию происходят в 3 ночи). В лучшем случае приводит к замедлению процесса, а если ОС перегружается для применения апдейтов, то бэкап будет испорчен. Хорошо еще, что апдейты ОС не каждый день случаются.
Рекомендации: Если нельзя отключить, то назначьте апдейты ОС на такое время, когда они не смогут помешать бэкапам.

11. Бэкап базы данных средствами файлового бэкапа или средствами бэкапа виртуальной машины целиком, при включенном сервере БД
Многие администраторы забывают о том факте, что любая СУБД имеет активный и сложный кэш, в котором содержатся читаемые и записываемые данные, а сами файлы БД открываются в режиме случайного доступа.
Именно поэтому необходимо использовать специальные виды бэкапа, а не простой файловый бэкап (включая простое копирование файлов БД) или бэкап виртуальной машины. Файловые средства бэкапа читают БД последовательно и, особенно для больших БД, могут идти продолжительное время, поэтому нельзя гарантировать целостность созданной копии.
Для желающих осуществлять бэкап БД с помощью файловых средств или средств бэкапа виртуальных машин можно предложить 2 способа:

  1. полностью выключать сервисы и процессы СУБД, чтобы ничего не находилось в кэше,
  2. использовать агенты и/или скрипты, переводящие базы данных в специальный режим, когда копирование файла БД последовательным образом является безопасным.

Для Firebird необходимо блокировать основной файл БД с помощью nbackup до начала резервного копирования и разблокировать после окончания, для других СУБД есть аналогичные средства включения/выключение соответствующих режимов.

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

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

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

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

Ну, и конечно – не забывайте холить и лелеять свою админскую паранойю, например, возьмите и проверьте свои бэкапы… вот прямо сейчас!

UPDATE

Господа, просьба откликнуться в личку тех, кто использует CBT на VMWare для ВМ с БД.

Хранение, резервное копирование и каталогизация фотографий / Habr

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

Домашний сервер, где происходит многое из описанного ниже:

Что надо сохранять?


Самое важное и объёмное у меня — фотографии. Изредка видео, но очень изредка — оно слишком много места занимает и слишком много времени отнимает, потому я его не слишком люблю, снимаю только короткие ролики, которые валяются в той же куче, где и фотографии. На текущий момент фотоархив у меня занимает примерно 1,6 терабайта и растёт где-то на 200 гигабайт в год. Другие важные вещи гораздо менее объёмны и с ними меньше вопросов в плане хранения и бэкапа, десяток-другой гигабайт можно распихать по куче бесплатных или очень дешевых мест, начиная от ДВД и заканчивая флэшками и облаками.

Как оно хранится и бэкапится?


Весь мой фотоархив занимает порядка 1,6 терабайта на текущий момент. Мастер-копия хранится на двухтерабайтном SSD в домашнем компьютере. На картах памяти я стараюсь не держать фотографии дольше необходимого, при первой возможности сливаю на десктоп или ноутбук (когда в дороге). Хотя с флэшки при этом не удаляю, если ещё место есть. Лишняя копия никогда не помешает. С ноута по приезду домой тоже всё скидывается на десктоп.

Ежедневно делается копия папки с фотографиями на домашний сервер (с типа зеркалом на базе Drivepool, где настроено дублирование важных папок). Кстати, Drivepool по прежнему рекомендую — за все годы использования ни одного глюка. Просто работает. Не надо только смотреть на его русский интерфейс, я отправил разработчикам более пристойный перевод, но не знаю, когда его внедрят (update: сказали, что в ближайшем релизе постараются). А пока что на русском языке это программа для управления бассейном (manage pool).

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

До недавнего времени с того же десктопа тем же GoodSync файлы загружались в облако Onedrive. Большая часть файлов у меня не персональные, потому закачивал как есть, без шифрования. Что было персональным — закачивалось отдельным заданием, с шифрованием.

Onedrive был выбран из-за того, что подписка Office 365 Home Premium за 2000 в год давала пять (а сейчас уже шесть) терабайт в облаке. Пусть и кусочками по терабайту. Сейчас, правда, халява несколько подорожала, но несколько недель назад были ещё вариант за 2600-2700 в год (надо искать искать у розничных продавцов). Я это предвидел, когда в прошлом году MS задрал цены, да ещё и прекратил на сайте подписку продавать, потому активировал подписку на пять лет вперёд пока ещё были в продаже по 1800-2000 коробки (можно, конечно, было ещё и несколько коробок про запас взять, но настолько далеко я загадывать не решился).

Скорость закачки — максимальная для моего тарифа, 4-5 мегабайт/сек., по ночам до 10. В своё время смотрел на crashplan — там хорошо если мегабайт в секунду грузился.

Пожизненные 5ТБ за 2-3$ c ebay — штука очень рэндомная. Ибо срок жизни может оказаться очень коротким, пока что три месяца рекорд. Не дело это — бэкапиться в то место, которое может накрыться в любой момент. Пусть и за копейки.

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

Учитывая то, что терабайты у меня кусочками, бэкап в облако состоит из нескольких заданий. Тут как раз идёт перезаливка бэкапа в облако. 2019 залился быстро — там за пару дней полсотни фото, я мало пока что ездил, а 2018 потихоньку льётся. Текущая скорость закачки не максимальная — день, каналы загружены и всё такое.

В облаке папка с бэкапом выглядит так — много zip-архивов, размер архива настраивается при создании задания:

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

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

Как оно каталогизируется?


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

Да, фотографирую я в равы. Потому что из raw в любой момент можно сделать jpg, но не наоборот. Когда-то снимал в raw+jpg, чтобы была возможность быстро перекинуть фото на телефон и отправить в интернет (raw на телефон передать было сложно). jpg потом стирал при копировании на десктоп. Но сейчас телефон меня стал устраивать по качеству фото (для выкладывания в интернет), потому от jpg на фотоаппаратах полностью отказался. Остались либо с тех времён, когда у меня не было беззеркалки, либо приходят с телефона.

На уровне файловой системы выглядит как-то так: на верхнем уровне папок — источник. Имена фотографов обычно.

Уровнем ниже — темы. У всех более-менее одинаковые, могут быть персональные темы (к примеру «Собаки», каких-то тем может не быть.

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

В итоге путь к файлу может выглядеть примерно так: Моё\Поездки\2018\2018-04-11 Берлин\Французский вокзал\P4110029.ORF

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

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

Логическая каталогизация поверх папок — Adobe Lightroom. Конечно, программ для каталогизации и обработки достаточно много, но лайтрум меня устраивает, вполне подъёмно стоит (и даже фотошоп в комплекте дают), а за последние пару лет ещё и тормозить меньше стал. Хотя, конечно, тут ещё и полный переход на SSD помог.

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

На основе всего вышеперечисленного можно создавать «умные коллекции» — динамические выборки по определённым свойствам файла — от параметров съёмки до текста в комментариях.

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

А что всё про фото? Что, других типов файлов нет?


Есть, почему нету. Методы бэкапа не отличаются (если вообще надо бэкапить), а методы каталогизации от типа контента зависят.

В основном хватает сортировки на уровне папок, теги не нужны. Только для фильмов и сериалов отдельный каталогизатор используется. — Plex Media Server. Он же и медиасервер, как следует из названия. Но там конь не валялся, нормально отсортирована хорошо если четверть фильмотеки, а остальное валяется в папке "!to sort".

Резервное копирование — Википедия

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

Резервное копирование (англ. backup copy) — процесс создания копии данных на носителе (жёстком диске, дискете и т. д.), предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Наименование операций

  • Резервное копирование данных (резервное дублирование данных) — процесс создания копии данных.
  • Восстановление данных — процесс восстановления в оригинальном месте.

Цель

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

Кроме этого, решается проблема передачи данных и работы с общими документами.

Требования к системе резервного копирования

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

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

  • RPO — Recovery Point Objective;
  • RTO — Recovery Time Objective.

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

Виды резервного копирования[1][2]

Полное резервное копирование (Full backup)
Полное копирование обычно затрагивает всю систему и все файлы. Еженедельное, ежемесячное и ежеквартальное резервное копирование подразумевает создание полной копии всех данных. Обычно оно выполняется тогда, когда копирование большого объёма данных не влияет на работу организации. Для предотвращения большого объёма использованных ресурсов используют алгоритмы сжатия, а также сочетание этого вида с другими: дифференциальным или инкрементным. Полное резервное копирование незаменимо в случае, когда нужно подготовить резервную копию для быстрого восстановления системы с нуля.
Дифференциальное резервное копирование (Differential backup)
При дифференциальном («разностном») резервном копировании каждый файл, который был изменён с момента последнего полного резервного копирования, копируется каждый раз заново. Дифференциальное копирование ускоряет процесс восстановления. Все копии файлов делаются в определённые моменты времени, что, например, важно при заражении вирусами.
Инкрементное резервное копирование (Incremental backup)
При добавочном («инкрементном») резервном копировании происходит копирование только тех файлов, которые были изменены с тех пор, как в последний раз выполнялось полное или добавочное резервное копирование. Последующее инкрементное резервное копирование добавляет только файлы, которые были изменены с момента предыдущего. Инкрементное резервное копирование занимает меньше времени, так как копируется меньшее количество файлов. Однако процесс восстановления данных занимает больше времени, так как должны быть восстановлены данные последнего полного резервного копирования, а также данные всех последующих инкрементных резервных копирований. В отличие от дифференциального копирования, изменившиеся или новые файлы не замещают старые, а добавляются на носитель независимо.
Клонирование
Клонирование позволяет скопировать целый раздел или носитель (устройство) со всеми файлами и каталогами в другой раздел или на другой носитель. Если раздел является загрузочным, то клонированный раздел тоже будет загрузочным[3].
Резервное копирование в виде образа
Образ — точная копия всего раздела или носителя (устройства), хранящаяся в одном файле[4].
Резервное копирование в режиме реального времени
Резервное копирование в режиме реального времени позволяет создавать копии файлов, каталогов и томов, не прерывая работу, без перезагрузки компьютера.[5]
Холодное резервирование
При холодном резервировании база данных выключена или закрыта для потребителей. Файлы данных не изменяются и копия базы данных находится в согласованном состоянии при последующем включении.[6]
Горячее резервирование
При горячем резервировании база данных включена и открыта для потребителей. Копия базы данных приводится в согласованное состояние путём автоматического приложения к ней журналов резервирования по окончании копирования файлов данных.[6]

Схемы ротации

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

Одноразовое копирование

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

Простая ротация

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

«Дед, отец, сын»

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

«Ханойская башня»

Схема призвана устранить некоторые из недостатков схемы простой ротации и ротации «Дед, отец, сын». Схема построена на применении нескольких наборов носителей. Каждый набор предназначен для недельного копирования, как в схеме простой ротации, но без изъятия полных копий. Иными словами, отдельный набор включает носитель с полной недельной копией и носители с ежедневными инкрементальными (дифференциальными) копиями. Специфическая проблема схемы «ханойская башня» — её более высокая сложность, чем у других схем.

«10 наборов»

Данная схема рассчитана на десять наборов носителей. Период из сорока недель делится на десять циклов. В течение цикла за каждым набором закреплён один день недели. По прошествии четырёхнедельного цикла номер набора сдвигается на один день. Иными словами, если в первом цикле за понедельник отвечал набор номер 1, а за вторник — номер 2, то во втором цикле за понедельник отвечает набор номер 2, а за вторник — номер 3. Такая схема позволяет равномерно распределить нагрузку, а следовательно, и износ между всеми носителями.

Схемы «Ханойская башня»[источник не указан 2493 дня] и «10 наборов» используются нечасто, так как многие системы резервного копирования их не поддерживают.

Хранение резервной копии

Причины утери информации

Эксплуатационные поломки носителей информации

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

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

  • RAID 1, обеспечивающий восстановление самой свежей информации. Файлы, расположенные на сервере с RAID, более защищены от поломок, чем хранящиеся на локальной машине;
  • Ручное или автоматическое копирование на другой носитель. Для этого может использоваться система контроля версий, специализированная программа резервного копирования или подручные средства наподобие периодически запускаемого cmd-файла.

Стихийные и техногенные бедствия

Описание: шторм, землетрясение, кража, пожар, прорыв водопровода — всё это может привести к потере всех носителей данных, расположенных на определённой территории.

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

Вредоносные программы

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

Борьба:

  • Установка антивирусных программ на рабочие станции. Простейшие антивирусные меры — отключение автозагрузки, изоляция локальной сети от Интернета, и т. д.
  • Обеспечение централизованного обновления: первая копия антивируса получает обновления прямо из Интернета, а другие копии настроены на папку, куда первая загружает обновления; также можно настроить прокси-сервер таким образом, чтобы обновления кэшировались (это всё меры для уменьшения трафика).
  • Иметь копии в таком месте, до которого вирус не доберётся — выделенный сервер или съёмные носители.
  • Если копирование идёт на сервер: обеспечить защиту сервера от вирусов (либо установить антивирус, либо использовать ОС, для которой вероятность заражения мала). Хранить версии достаточной давности, чтобы существовала копия, не контактировавшая с заражённым компьютером.
  • Если копирование идёт на съёмные носители: часть носителей хранить (без дописывания на них) достаточно долго, чтобы существовала копия, не контактировавшая с заражённым компьютером.
  • Использование носителей с однократной записью: CD-R, DVD-R, BD-R. Их объём недостаточен для серьёзных применений.

Человеческий фактор

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

Борьба:

  • Тщательно расставить права на все ресурсы, чтобы другие пользователи не могли модифицировать чужие файлы. Исключение делается для системного администратора, который должен обладать всеми правами на всё, чтобы быть способным исправить ошибки пользователей, программ и т. д.
  • Построить работающую систему резервного копирования — систему, которой люди реально пользуются и которая достаточно устойчива к ошибкам оператора. Если пользователь не пользуется системой резервного копирования, вся ответственность за сохранность ложится на него.
  • Хранить версии достаточной давности, чтобы при обнаружении испорченных данных файл можно было восстановить.
  • Перед переустановкой ОС следует обязательно копировать всё содержимое раздела, на которой будет установлена ОС, на сервер, на другой раздел или на CD/DVD.
  • Оперативно обновлять ПО, которое заподозрено в потере данных.

Затруднения при резервном копировании

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

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

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

См. также

Ссылки

Примечания

Отправить ответ

avatar
  Подписаться  
Уведомление о