Полное резервное копирование — определение полного резервного копирования

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

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

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

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

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

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

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

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

С опцией -a («Архив») команда копирования создает точную копию: временные метки, права доступа и т.д. целевых данных устанавливаются на точные значения соответствующих источников. Это очень важно, в частности, для систем, включающих код, таких как WordPress. Если копия создается без использования опции архивирования, существует риск возникновения уязвимостей в системе безопасности или потери функциональности.

Широко распространенным методом создания полной резервной копии является создание архива tarball. Для этого мы используем команду Linux-tar (название расшифровывается как «Tape Archive») для создания одного файла из нескольких файлов или каталогов. Для этого в качестве первого параметра должен быть указан целевой файл:

Параметр -z указывает команде tar использовать сжатие Gzip. Полученный файл .tar.gz обычно в 2-10 раз меньше, чем общий размер данных, включенных в резервную копию.

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

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

Как и в команде cp, для создания точной копии используется опция -a для «архива». В нашем примере предполагается, что копируемый каталог еще не существует по указанному пути. Если каталог уже существует на источнике, Rsync интеллектуально переносит только изменения, произошедшие после последней операции копирования. В этом случае копирование определяется уже не как полное, а как дифференциальное.

Команды cp и Rsync — это инструменты Linux. Они также доступны в Windows через WSL2 («Windows Subsystem for Linux»). С помощью Robocopy доступна альтернатива, специфичная для Windows. Это особенно полезно, поскольку файловая система NTFS, используемая в Windows, имеет некоторые особенности.

Как и аналог для Linux, Robocopy Backup используется из командной строки. Помимо очевидной связи с Робокопом, название инструмента расшифровывается как «Robust File Copy». Давайте рассмотрим пример команды Robocopy. Мы зеркалируем исходный каталог на путь назначения:

Опция /mir означает «зеркало». Robocopy создает полную резервную копию исходного каталога. Место назначения и источник находятся на локальной системе или на общем ресурсе Windows, подключенном по сети. В отличие от Rsync, Robocopy не поддерживает копирование через SSH-соединение.

Для создания резервных копий на Mac или Windows 10 можно использовать интегрированные в систему инструменты Time Machine или Windows Backup. При первом запуске обоих инструментов создается полная резервная копия. При последующих резервных копиях переносятся только изменения, произошедшие после последней резервной копии. Система может быть полностью восстановлена из полной резервной копии.

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

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

Существует три основных преимущества создания полной резервной копии:

1. Простота настройки: достаточно штатных инструментов.
2. Самый надежный метод резервного копирования: низкий риск потери данных
3. Простота восстановления: обычно достаточно обратного процесса копирования.

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

1. На целевой системе имеется достаточно памяти.
2. Имеется достаточная пропускная способность для завершения процесса копирования за приемлемое время.

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

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

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

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

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

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

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

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

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

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

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

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

Однако есть принципиальное отличие от миграции системы: при перезагрузке исходная система теряется. Лучше всего следовать правилу 3-2-1-backup-rule и создать как минимум две полные резервные копии системы в разных местах. Перед перезапуском следует также протестировать процесс восстановления.

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

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

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

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