Бэкап системы что это
Что такое «backup»?
Очень часто я слышу фразы вроде «зачем мне бэкап, у меня же есть RAID!». Или «я делаю бэкапы на второй HDD в сервере!». Или что-то подобное. Очень часто через несколько месяцев после этого я слышу вопрос «а как мне восстановить убитые данные?». И это печалит.
В статье я хочу немного порассуждать о том, что такое «резервное копирование» и какая схема такого копирования поможет защититься от потери своих данных. Ну и попытаться обличить некоторые мифы и вредные привычки.
Большинство, думаю, ничего для себя нового не найдет, но если вы все еще относитесь к категории тех, кто бэкапы не делает или делает, но это не бэкапы — добро пожаловать!
Требования?
Давайте определимся с терминологией. Что такое резервная копия?
Логично предположить, что это копия данных, предварительно сохраненная с целью восстановления в случае уничтожения оригинала.
Отсюда вытекает первое требование — изолированность. Не имеет смысла делать копию документов на квартиру и хранить ее там же, где оригинал. Так не имеет смысла делать копию данных и хранить ее на том же диске/в том же сервере, что и оригинал. Логично? Вполне.
Едем дальше. Если мы делаем копию данных, значит, боимся их потерять. Так? Так. Значит, все резервируемые данные для нас ценны. Так? Снова так. Отсюда второе требование — целостность. Не смысла в копировании без проверки целостности — на выходе мы вполне можем получить битые данные или потерять часть безвозвратно.
Ну и хватит, наверное. Статья ориентирована на SOHO-пользователей, а не на энтерпрайз, поэтому требования к безопасности, скорости disaster recovery, ограниченной избыточности и прочему мы рассматривать не будем.
И что в итоге?
В итоге мы получили три требования, которым должна соответствовать система резервного копирования для того, чтобы носить это гордое имя и надежно хранить ваши данные. Изолированность защитит от сбоя оборудования или внешних факторов (пожара, потопа и т.д.), а также злонамеренного удаления данных (не позволит злоумышленнику или вирусу заразить/удалить и бэкап тоже), контроль целостности гарантирует, что зарезервированы все ваши данные и вы не останетесь у разбитого корыта при утрате основного экземпляра, узнав о проблемах слишком поздно, версионированность не даст бэкап-системе переместить пулю из ноги пользователя, который прострелил себе колено — ему же в голову.
Ближе к практике.
Анализируя существующую или придумывая для себя новую СРК — подумайте, соответствует ли она критериям, изложенным выше?
Пересекаются ли в одном месте основная и резервная копия? Обеспечивается ли при этом изолированность резервной? Существует ли возможность одновременно изменять файлы в основном и резервном хранилище? Существует ли значительная (более значительная, чем атомный взрыв) вероятность того, что оба носителя будут одновременно уничтожены или утеряны? Если ответ на любой из этих вопросов «да» — в системе есть ошибка. К примеру, если вы сделали бэкап файлов с ноутбука на usb flash и убрали ее в сейф — вы молодец. Если вы сделали этот бэкап и положили флешку в сумку к ноутбуку — вы не сделали бэкап.
Обеспечивает ли ваша схема целостность данных? К примеру, если на резервном носителе закончится место и копия не сможет корректно сохраниться — вы об этом узнаете?
Обеспечивает ли она полноту? Если это приложение — сохранены ли настройки, если база данных — схема и т.д.?
Можно ли из существующей копии получить работающий оригинал? Или чего-то не хватает?
Представляете ли вы себе, что будете делать, если потеряете основные данные? Есть ли (пусть простейшая) методика восстановления? Все ли ее пункты выполнимы и достаточны для получения данных? Практике известны примеры, когда бэкап делался на зашифрованный HDD, а сложный и безопасный ключ шифрования хранился не в голове у владельца и даже не на желтой бумажке, а… да-да, на том ноутбуке, откуда и делался бэкап. Как вы понимаете, при краже ноутбука данные были утрачены безвозвратно.
Проведите «учения» — представьте, что основной носитель утрачен и попытайтесь восстановиться. Уверен, с первого раза у вас ничего не выйдет, или выяснится, что многое на самом деле не совсем так, как вы представляли ранее.
Ответили? Провели? Все прекрасно? Нет, не совсем. Не забывайте о СРК. Поддерживайте ее в актуальном состоянии. Начали использовать новое ПО? Внесите его каталоги в список на бэкап. Подумайте, как его восстанавливать. Следите за состоянием резервного носителя (если это одиночный диск, флешка или NAS — он совсем не вечный). Думайте о своих данных, кроме вас этого не сделает никто.
Мифы и примеры плохих решений
Утилиты вроде dropbox тоже для бэкапа мало годятся — если, конечно, не предусмотрена версионируемость. Случайно испортив данные в основной копии вы потеряете и резервную, едва между ними синхронизируются изменения. Данные будет уже не вернуть.
Вместо заключения
Берегите свои данные, потратив 15 минут «до» — можно сэкономить 15 часов «после». Не забывайте бородатый анекдот про тех, кто не делает бэкапы и тех, кто их уже делает.
Что такое бэкап (backup) — Разбираемся на примерах
Давайте разберемся, как это делать на примерах.
Зачем делать бэкап
При хранении любой информации на одном носителе рано или поздно она будет утеряна.
К примеру, если на компьютере за несколько лет скопилось много файлов: фотографии, видео, различные документы, переписка с кем-то.
И если всё это хранится на одном компьютере, то в один «прекрасный миг» всё это пропадёт, неважно насколько мощный компьютер.
Никто не застрахован от короткого замыкания, неисправностей из-за некачественных комплектующих компьютера. Или просто из-за выхода из строя жесткого диска. Всё это будет безвозвратно утеряно.
Потому что не бывает на 100% надёжной техники, всё когда-то ломается. И никто не знает, когда это произойдёт.
Бэкап документов
В процессе работы с документами мы можем работать дни и даже недели.
Далее, удаляем какие-то фрагменты работы, вносим новые, снова сохраняем.
Затем видим, что изменения нас не устраивают и хотим вернуть прежний вариант, но он уже изменён.
В этом случае можно создавать для каждой правки новую копию.
Тогда при случайном удалении файла его можно восстановить из другой копии.
Если прошло немного времени и не были использованы утилиты для оптимизации Windows.
Они выметают мусор отовсюду, со всех дальних, и не очень, уголков системы и с корзины тоже, в этот раз безвозвратно.
При работе в Гугл Документах при случайном удалении, в этом сервисе существует функция восстановления старых версий документа.
Носители для бэкапа
В качестве хранилища для бэкапа используйте:
Полный бэкап Windows
Полный бэкап Windows
Операционные системы Windows обладают широкой функциональностью.
Среди многочисленных функций — резервное копирование, архивация и восстановление.
До версии Windows 7, функция архивации и восстановления также была и в ранних ОС, но пользователи предпочитали пользоваться сторонними программами.
В «семёрке» она была основательно переработана и стала на порядок лучше.
В этом случае нужно иметь полную копию Windows со всеми программами и драйверами.
Для пользовательских персональных компьютеров, на которых хранится только информация развлекательного характера, фильмы, музыка — необязательно резервирование.
Так как всю эту информацию можно легко скачать и восстановить из интернета.
Для того, чтобы создать резервную копию Windows зайдите в «Панель управления».
Выберите «Система и безопасность». «Архивация и восстановление». В «десятке» этот раздел называется — «Резервное копирование и восстановление».
Выберите «Настроить резервное копирование».
Настраиваем резервное копирование
В окне настройки архивации выберите носитель для хранения архива. Это не должен быть логический раздел, на котором лежит Windows. Можно хранить резервные копии на уделённом сервере.
Выбираем диск, где сохраним данные
Отметьте пункт выбора файлов для восстановления (совет установить маркер на самостоятельный выбор).
Выбираем папки для архивации
Выбираем нижний пункт
В следующем окне проверьте, все ли разделы отмечены. Откройте ссылку «Изменить расписание». Здесь выберите вариант расписания архивации, еженедельно, другой период, или совсем отключите расписание чтобы не засорять полезное дисковое пространство резервными копиями, которые, к слову, не мало весят.
Выбираем время архивации
Бэкап канала Youtube
Бэкап канала Youtube
И если случается непредвиденная ситуация, например, если его закрыли, или какая-то редиска подаст на него страйк.
Случится может многое, а канал один и вы им очень дорожите — во избежание подобных казусов целесообразно делать бэкап своего канала.
Такое случается, когда неопытный ютубер выкладывает один и тот же ролик на два канала.
Это не одобряется, ни самим Ютубом, ни поисковыми роботами Google, ни самими пользователями.
Либо канал не будут смотреть из-за копипаст, либо его вовсе заблокируют за спам.
Но можно выложить копии видео на другой канал, но не публиковать его.
В таком случае, при непредвиденной ситуации, которая может приключиться с основным каналом, резервный канал можно тут же опубликовать и никаких банов и фильтров.
Способ 1
Скопируйте готовое видео на жесткий диск.
Для этого можно обзавестись недорогим съёмным USB-жестким диском, на котором можно создать папки для удобной навигации если роликов много.
Способ 2
Скачайте всё видео с Ютуб канала при помощи сервисов Google.
Войдите в аккаунт Google, к которому привязан канал.
Далее «Мой аккакунт» — в разделе конфиденциальность «Управление контентом» — «Создать архив».
С помощью этого инструмента можно скачать в архив всю информацию со всех сервисов Google, привязанных к конкретному аккаунту.
Из всего списка сервисов выберите Ютуб;
Нажмите кнопку «Создать архив».
Если канал большой запаситесь терпением, это может быть большой файл и на его скачивание понадобится время.
Что такое BackUp блога WordPress
BackUp блога WordPress
Сайты и блоги на WordPress часто подвергаются хакерским атакам.
Ничего личного, это работа ботов — задача хакерской атаки поместить вредоносный код в файлы блога, чтобы в дальнейшем он работал на взломщиков. Необходимо создавать резервную копию блога.
Самое ценное это контент, картинки, статьи, пути к картинкам ссылки. — всё это хранится в базе данных.
Когда нужно делать бэкап сайта или блога WordPress?
Файлы для резервного копирования.
Копирование файлов происходит в архив. А база данных копируется в один файл с расширением cql.
Резервная копия Android
Резервную копию всех данных Android нужно делать во избежание потери информации при поломке телефона, утере его, или при замене.
Наиболее лёгкий способ восстановления удалённых приложений — Google Play хранит список всех когда-либо установленных приложений и игр на любое андроид-устройство, привязанное к учетной записи Google.
Этот список находится по пути «Меню» — «Мои приложения и игры» — «Библиотека».
Здесь можно восстановить только приложения и игры, которые были установлены Google Play.
Все игры и приложения, установленные в обход маркета здесь отображаться, не будут.
Восстановление и создание резервной копии Android
Делаем резервную копию
В эту резервную копию будут помещены все данные с телефона. В любой момент её можно восстановить
Программы для восстановления информации
Стоимость восстановления информации
Если на компьютере установлено больше одного жёсткого диска (не путать с логическими разделами C, D, E, F…), из строя может выйти только один из них (сломаться все жесткие диски одновременно не могут), при хранении копий на двух и более носителях шансы потерять важную информацию крайне малы (за исключением пожара, но это совсем печальный исход).
Стоимость восстановления данных с поломанного жесткого диска очень высока, она может достигать и 5 тыс. и даже 10 тыс. рублей — не очень радужная перспектива.
Иногда с повреждённого диска и вовсе невозможно восстановить информацию. То же касается сайтов и блогов.
Хостинг, на котором хранится весь контент может неожиданно поломаться, тогда труды многих лет, силы и вложенные деньги исчезнут в небытие без своевременного бэкапа.
Выводы
Выполняйте backup только ценной информации — фильмы, стоковые картинки, игры и прочее не являются уникальной информацией, их можно скачать из интернета и всегда восстановить. К тому же они будут занимать на носителе много места.
Альтернативный способ хранения фотографий и видео — социальные сети, однако, при хранении мультимедийной уникальной информации в социальных сетях их качество существенно снижается, лучше, всё-таки, хранить оригинальные копии фото на съёмном жёстком диске или облаке.
Резервное копирование, часть 1: Назначение, обзор методов и технологий
Идеальная программа работает быстро, не течет по оперативной памяти, не имеет дыр и не существует.
Поскольку программы все еще пишутся белковыми разработчиками, а процесс тестирования зачастую отсутствует, плюс поставка программ крайне редко происходит с применением «best practices» (которые сами по себе тоже программы, а следовательно, неидеальны), системным администраторам чаще всего приходится решать задачи, которые звучат кратко, но емко: «вернуть, как было», «привести базу к нормальной работе», «медленно работает — откатываем», а также мое любимое «не знаю что, но почини».
Кроме логических ошибок, которые вылезают в результате небрежной работы разработчиков, либо стечения обстоятельств, а также неполного знания или непонимания мелких особенностей построения программ — в том числе связующих и системных, включая операционные системы, драйвера и прошивки, — есть еще и другие ошибки. Например большинство разработчиков полагается на рантайм, совершенно забывая о физических законах, обойти которые с помощью программ все еще невозможно. Это и бесконечная надежность дисковой подсистемы и вообще любой подсистемы хранения данных (включая оперативную память и кэш процессора!), и нулевое время обработки на процессоре, и отсутствие ошибок при передаче по сети и при обработке на процессоре, и задержки сети, которые равны 0. Не стоит пренебрегать и пресловутым дедлайном, ведь если к нему не успеть — будут проблемы почище нюансов работы сети и диска.
Как же быть с проблемами, которые встают в полный рост и нависают над ценными данными? Живых разработчиков заменить нечем, да и не факт, что можно будет в ближайшее время. С другой стороны, полностью доказать, что программа будет работать как задумано, пока что получилось только у нескольких проектов, и совершенно не обязательно можно будет взять и применить доказательства на другие, схожие проекты. Также подобные доказательства занимают уйму времени, и требуют особых навыков и знаний, а это практически сводит к минимуму возможность их применения с учетом дедлайнов. К тому же мы еще не умеем в сверхбыструю, дешевую и бесконечно надежную технологию хранения, обработки и передачи информации. Подобные технологии, если и существуют, то в виде концептов, либо — чаще всего — только в фантастических книгах и фильмах.
Хорошие художники копируют, великие художники воруют.
Самые удачные решения и удивительно простые вещи обычно происходят там, где встречаются абсолютно несовместимые, на первый взгляд, понятия, технологии, знания, области наук.
Например, у птиц и у самолетов есть крылья, однако несмотря на функциональную схожесть — принцип действия в некоторых режимах совпадает, и технические проблемы решаются аналогично: полые кости, использование прочных и легких материалов и т.п., — результаты абсолютно разные, хоть и весьма похожие. Лучшие образцы, которые мы наблюдаем в нашей технике, также по большей части заимствованы у природы: герметичные отсеки у кораблей и подводных лодок — прямая аналогия с кольчатыми червями; построение raid-массивов и проверка целостности данных — дублирование цепочки ДНК; а также парные органы, независимость работы разных органов от ЦНС (автоматия работы сердца) и рефлексы — автономные системы в Интернет. Конечно брать и применять готовые решения «в лоб» чревато проблемами, но кто знает, может, других решений-то и нет.
Знать бы, где упадешь — соломки подстелил бы!
—Белорусская народная пословица
Значит, резервные копии жизненно необходимы тем, кто желает:
Любая классификация произвольна. Природа не классифицирует. Классифицируем мы, потому что для нас так удобнее. И классифицируем по данным, которые мы берем также произвольно.
Независимо от физического способа хранения логическое хранение данных можно условно разделить по 2 способам доступа к этим данным: блочное и файловое. Такое деление в последнее время весьма размыто, ведь чисто блочных, как и чисто файловых, логических хранилищ не существует. Однако для простоты будем считать, что они есть.
Блочное хранение данных подразумевает, что есть физическое устройство, куда записывают данные некоторыми фиксированными порциями, блоками. Доступ к блокам идет по некоторому адресу, каждому блоку соответствует свой адрес в пределах устройства.
Резервная копия обычно делается путем копирования блоков данных. Для обеспечения целостности данных на момент копирования приостанавливается запись новых блоков, а также изменение существующих. Если брать аналогию из обычного мира — ближе всего шкаф с одинаковыми пронумерованными ячейками.
Файловое хранение данных по принципу логического устройства близко к блочному и зачастую организуется поверх. Важные различия — наличие иерархии хранения и человекопонятные имена. Выделяется абстракция в виде файла — именованной области данных, а также каталога — специального файла, в котором хранятся описания и доступы к другим файлам. Файлы могут снабжаться дополнительными метаданными: время создания, флаги доступа и т.п. Резервируют обычно так: ищут измененные файлы, потом копируют их в другое, одинаковое по структуре файловое хранилище. Целостность данных обычно реализуют путем отсутствия файлов, в которые идет запись. Метаданные файлов резервируются аналогично. Ближайшая аналогия — библиотека, в которой есть разделы с разными книгами, а также есть каталог с человекопонятными именами книг.
В последнее время иногда описывают еще один вариант, с которого, в принципе, и началось файловое хранение данных, и у которого есть те же архаичные черты: объектное хранение данных.
От файлового хранения отличается тем, что не имеет вложенности больше одного (плоская схема), а имена файлов хотя и человекочитаемые, но все же больше приспособлены для обработки машинами. При резервном копировании объектные хранилища чаще всего обрабатывают подобно файловым, но изредка есть и другие варианты.
— Есть два вида системных администраторов, те кто не делает резервные копии, и те, кто УЖЕ делает.
— На самом деле три вида: есть еще те, кто проверяет, что резервные копии можно восстановить.
Также стоит понимать, что сам процесс резервного копирования данных осуществляется программами, поэтому ему присущи все те же минусы, как и другой программе. Чтобы убрать (не исключить!) зависимость от человеческого фактора, а также особенностей — которые по отдельности не сильно влияют, но вместе могут дать ощутимый эффект, — применяют т.н. правило 3-2-1. Есть много вариантов, как его расшифровать, но мне больше нравится следующая трактовка: хранить надо 3 набора одних и тех же данных, 2 набора надо хранить в разных форматах, а также 1 набор надо иметь на географически удаленном хранилище.
Под форматом хранения следует понимать следующее:
С точки зрения готовности резервной копии по ее прямому назначению — восстановлению работоспособности, — различают «горячие» и «холодные» резервные копии. Горячие от холодных отличаются только одним: они сразу же готовы к работе, в то время как холодные для восстановления требуют некоторых дополнительных действий: расшифровки, извлечения из архива и т.п.
Не стоит путать горячие и холодные копии с online и offline копиями, которые подразумевают физическую изоляцию данных, и по сути, являются другим признаком классификации способов резервного копирования. Так offline копия — не подключенная непосредственно к системе, где ее надо восстановить, — может быть как горячей, так и холодной (с точки зрения готовности к восстановлению). Online копия может быть доступна непосредственно там, где ее надо восстанавливать, и чаще всего является горячей, но бывают и холодные.
Кроме того, не стоит забывать, что сам процесс создания резервных копий обычно не заканчивается на создании одной резервной копии, а копий может быть достаточно большое число. Следовательно, надо различать полные резервные копии, т.е. те, которые восстановимы независимо от других резервных копий, а также разностные (инкрементальные, дифференциальные, декрементальные и т.п.) копии — те, которые не могут быть восстановлены самостоятельно и требуют предварительного восстановления одной или нескольких других резервных копий.
Разностные инкрементальные копии — попытка сэкономить размер пространства для хранения резервных копий. Таким образом в резервную копию пишутся только измененные данные с прошлой резервной копии.
Разностные декрементальные создаются с той же целью, но немного другим путем: делается полная резервная копия, но реально хранится только разница между свежей копией и предыдущей.
Отдельно стоит рассмотреть процесс резервного копирования поверх хранилища, которое поддерживает отсутствие хранения дубликатов. Таким образом, если писать полные резервные копии поверх него, реально будет записана только разница между резервными копиями, однако процесс восстановления резервных копий будет происходить аналогично восстановлению с полной копии и полностью прозрачно.
(Кто устережет самих сторожей? — лат.)
Весьма неприятно, когда резервных копий нет, однако гораздо хуже, если резервная копия вроде бы и сделана, но при восстановлении выясняется, что она не может быть восстановлена, потому что:
Правильно построенный процесс резервного копирования обязан учитывать подобные замечания, особенно первые два.
Целостность исходных данных можно гарантировать несколькими способами. Наиболее часто используются следующие: а) создание слепков файловой системы на блочном уровне, б) «заморозка» состояния файловой системы, в) особое блочное устройство с хранением версий, г) последовательная запись файлов или блоков. Также применяются контрольные суммы, чтобы обеспечивать проверку данных при восстановлении.
Повреждения хранилища также можно обнаружить с помощью контрольных сумм. Дополнительный метод — применение специализированных устройств, либо файловых систем, в которых нельзя изменять уже записанные данные, но можно дописывать новые.
Для ускорения восстановления применяется восстановление данных с несколькими процессами для восстановления — при условии, что нет «бутылочного горлышка» в виде медленной сети или небыстрой дисковой системы. Для того, чтобы обойти ситуацию с частично восстановленными данными, можно разбить процесс резервного копирования на относительно небольшие подзадачи, каждая из которых выполняется отдельно. Таким образом, появляется возможность последовательно восстановить работоспособность с прогнозированием времени восстановления. Данная проблема чаще всего лежит в огранизационной плоскости (SLA), поэтому не будем останавливаться на этом подробно.
Знает толк в пряностях не тот, кто добавляет их в каждое блюдо, но тот, кто никогда не добавит в него ничего лишнего.
Практика в части применяемого ПО у системных администраторов может различаться, но общие принципы все равно, так или иначе, те же, в частности:
Для снятия резервных копий с блочных устройств есть следующие распостраненные программы:
Для файловых систем задача резервного копирования частично решается с помощью методов, применимых для блочных устройств, однако задачу можно решить и более эффективно, используя, например:
Итак, для небольшого сервера нужно обеспечить схему резервного копирования, отвечающую следующим требованиям:
В качестве тестового стенда будет применяться виртуальная машина (на базе XenServer) со следующими характеристиками:
Операционная система — Centos 7 x64: разбивка стандартная, дополнительный раздел будет использоваться как источник данных.
В качестве исходных данных возьмем сайт на wordpress, с медиафайлами размером 40 гб, базой данных на mysql. Так как виртуальные сервера весьма сильно различаются по характеристикам, а также для лучшей воспроизводимости, здесь есть
Prime numbers limit: 20000
Initializing worker threads…
CPU speed:
events per second: 836.69
Throughput:
events/s (eps): 836.6908
time elapsed: 30.0039s
total number of events: 25104
Latency (ms):
min: 2.38
avg: 4.78
max: 22.39
95th percentile: 10.46
sum: 119923.64
Threads fairness:
events (avg/stddev): 6276.0000/13.91
execution time (avg/stddev): 29.9809/0.01
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: read
scope: global
Initializing worker threads…
Total operations: 50900446 (1696677.10 per second)
49707.47 MiB transferred (1656.91 MiB/sec)
Throughput:
events/s (eps): 1696677.1017
time elapsed: 30.0001s
total number of events: 50900446
Latency (ms):
min: 0.00
avg: 0.00
max: 24.01
95th percentile: 0.00
sum: 39106.74
Threads fairness:
events (avg/stddev): 12725111.5000/137775.15
execution time (avg/stddev): 9.7767/0.10
Running memory speed test with the following options:
block size: 1KiB
total size: 102400MiB
operation: write
scope: global
Initializing worker threads…
Total operations: 35910413 (1197008.62 per second)
35068.76 MiB transferred (1168.95 MiB/sec)
Throughput:
events/s (eps): 1197008.6179
time elapsed: 30.0001s
total number of events: 35910413
Latency (ms):
min: 0.00
avg: 0.00
max: 16.90
95th percentile: 0.00
sum: 43604.83
Threads fairness:
events (avg/stddev): 8977603.2500/233905.84
execution time (avg/stddev): 10.9012/0.41
Extra file open flags: (none)
128 files, 8MiB each
1GiB total file size
Block size 4KiB
Number of IO requests: 0
Read/Write ratio for combined random IO test: 1.50
Periodic FSYNC enabled, calling fsync() each 100 requests.
Calling fsync() at the end of test, Enabled.
Using synchronous I/O mode
Doing random r/w test
Initializing worker threads…
Throughput:
read: IOPS=3868.21 15.11 MiB/s (15.84 MB/s)
write: IOPS=2578.83 10.07 MiB/s (10.56 MB/s)
fsync: IOPS=8226.98
Latency (ms):
min: 0.00
avg: 0.27
max: 18.01
95th percentile: 1.08
sum: 238469.45