Что значит резервное копирование данных
Резервное копирование, часть 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
Как сделать бэкап и для чего он нужен
реклама
Среди айтишников ходит присказка-поговорка: «есть два типа людей – кто еще не делает бэкапы, и кто уже делает». И действительно, один раз потеряв ценную для себя информацию, и с трудом и большими денежными затратами восстановив ее, или вообще не сумев восстановить, вряд ли какой-то здравомыслящий человек захочет столкнуться с подобной ситуацией еще раз. В этой статье я расскажу о бэкапах (резервных копиях) данных – что это такое, зачем они нужны, как и где их делать.
Материал ориентирован не на системных администраторов и не на работников коммерческих фирм, а на пользователей домашних ПК и геймеров, поэтому информация будет подаваться в наиболее доступной форме, а многие профессиональные нюансы не будут затронуты. В этот раз я не стану рассказывать о полностью автоматизированных бэкапах и тому подобных вещах – эта статья о ручном создании резервных копий особо ценных данных и их последующем беспроблемном восстановлении.
Что такое бэкап простыми словами?
Бэкап – это резервная копия каких-либо данных. Например, в вашем компьютере установлены 3 накопителя: SSD и два жестких диска – HDD 1 и HDD 2. На HDD 1 вы храните ценные для вас семейные фотографии, и вдруг он выходит из строя, унося с собой всю имеющуюся на нем информацию. Вы пробуете программы для восстановления данных с поврежденных «винчестеров», но ничего не помогает. Остается только одно – идти в специализированный сервис и отдавать кругленькую сумму. И то не факт, что помогут. А вот если бы эти фотографии были не в единственном экземпляре и хранились где-нибудь еще…
Как сделать бэкап?
реклама
Сделать резервную копию каких-либо файлов очень просто: их нужно скопировать на другой физический накопитель. Подчеркну: именно на другой физический накопитель, а не на другой «локальный диск». Физический накопитель (SSD или жесткий диск) может состоять из нескольких разделов. Простой пример из жизни: физический накопитель – это ящик для столовых приборов, а локальные диски – это разные отсеки; один для ножей, один для вилок, один для ложек и так далее. То есть, если у вас HDD 1 разбит на разделы D и E, а HDD 2 на разделы F и G, то недостаточно скопировать фотографии из раздела D в раздел E – необходимо «забэкапить» их в раздел F или G. Но находясь даже в нескольких экземплярах на одном компьютере или в одной квартире, данные все равно могут потеряться – например, в случае чрезвычайных обстоятельств вроде пожара. Вот простые правила, которые помогут этого избежать.
Главные правила резервного копирования
Правило первое: для действительно важных данных должно существовать как минимум три бэкапа, физически находящихся в разных местах, причем парочка из них – на удаленных серверах. В случае пожара, затопления и других форс-мажорных обстоятельств вы легко можете лишиться всех электронных устройств, находящихся в одной квартире, поэтому бэкапов «по месту жительства» недостаточно. Но почему я предлагаю именно два удаленных сервера? Да потому что, если такой сервер один, с ним тоже может случиться форс-мажор (сгорел дата-центр, закрылась компания, случайно стерли данные), а вы об этом узнаете только если потеряете «оригинальные» данные и их копию по месту жительства.
реклама
Если вы используете для бэкапов бесплатные хранилища, хостинги и файлообменники – будьте готовы, что они в любой момент могут решить стереть ваши данные, и сделайте еще пару удаленных резервных копий. Да, муторно, но лучше так, чем потерять данные. И обязательно защитите свою информацию при помощи шифрования, не заливайте ее в открытом виде. О том, как это сделать, я расскажу в соответствующем разделе.
Правило второе: проверяйте бэкапы. Если бэкап не проверен, то можно считать, что его и нет. Браузер или программа закачки может показать, что все загрузилось успешно, а при попытке скачать, расшифровать или разархивировать – бац, ошибка. После создания бэкапов проведите пару тестовых восстановлений данных из разных источников.
Правило третье: если речь идет о домашнем ПК, делайте резервные копии только действительно важных данных. Нет никакой надобности бэкапить любимые игры или сериалы – если полетит SSD/жесткий диск, их всегда можно скачать заново. А вот уникальные и имеющиеся только у вас данные, такие, как сохраненки для игр, уже вполне можно бэкапить, если вы заядлый геймер. Но чаще всего в случае домашних бэкапов сохраняются копии личных/семейных фотографий и видео, а также заметок.
реклама
Выбор этих важных данных должен быть индивидуальным. Ценные для вас фото, скриншоты заметки, и тому подобное стоит бэкапить всегда (только не забывайте все это шифровать!), а дальше – как говорится, кто на что горазд. Если вы просидели много сотен часов в Скайриме, то стоит сделать резервную копию нескольких сохранений с разных этапов игры, если вы играете в покер на деньги – бэкапьте базу данных с информацией на оппонентов, если храните криптовалюту – бэкапьте кошельки или данные для доступа к ним.
Если говорить о бэкапах для коммерческих фирм, дата центров и т.д., существуют и некоторые другие правила – например, о том, что создание резервных копий должно быть автоматическим и не должно мешать повседневной работе и интересам клиентов, или о том, что необходимо минимизировать дублирование файлов ради экономии места, но подробно на них я останавливаться не буду – все это мало касается резервного копирования «домашней» информации.
Как защитить резервную копию данных на удаленном сервере при помощи шифрования?
Любые чувствительные данные вроде бэкапов личных заметок, фото и криптокошельков, следует защищать при помощи шифрования. Рекомендую использовать VeraCrypt – программу с открытым исходным кодом, которая в свое время стартовала как форк TrueCrypt. В настоящий момент она считается одним из самых надежных бесплатных решений для шифрования и используется журналистами, активистами и лицами, работающими с чувствительной информацией, по всему миру.
Выберите «Тома» – «Создать новый том», далее – «Создать зашифрованный файловый контейнер» – «Обычный том». Подойдет AES с алгоритмом хеширования SHA-512. После этого укажите максимальный размер тома – он должен быть таким, чтобы туда влезли все ваши файлы, резервную копию которых вы хотите создать. Введите подходящий пароль и подтвердите, что собираетесь хранить в контейнере файлы размером более 4 ГБ. Дальше следуйте указаниям программы. Жмите «разметить», а по окончанию шифрования монтируйте созданный контейнер и переносите туда нужные файлы, после чего размонтируйте.
Все, файлы зашифрованы, можно заливать том в облако/на удаленное хранилище! Если хотите, можете перед этим еще и заархивировать контейнер с паролем, чтобы уменьшить его размер, но это необязательно. Главное, не забудьте разархивировать/размонтировать бэкап и проверить его работоспособность перед тем, как начать загрузку, после же загрузки скачайте его и повторите процедуру. Это может занять немало времени, но, поскольку резервные копии домашних данных создаются нечасто – ничего страшного.
Заключение
Не ленитесь и не откладывайте создание бэкапа на потом, не думайте, что уж с вами потеря данных точно не случится – если у вас нет резервной копии какой-либо ценной информации, как можно скорее сделайте ее.
Правило резервного копирования «3-2-1». Часть 1
Считается, что бэкап-правило «3-2-1» впервые описал Peter Krogh в своей книге «Управление цифровыми активами для фотографов». И это, наверное, неудивительно, так как потеря личного архива означает для профессионального фотографа полную катастрофу, и он просто обязан придерживаться такой стратегии резервного копирования, которая гарантировано защитит его от потери данных.
Однако, увы, именно в реальной жизни часто имеет место быть статистическая зависимость угроз. Например, когда в цепи питания офиса возникает электромагнитный импульс, он одинаково воздействует на все диски сразу. И, если выходит из строя один диск, то, скорее всего, выйдут из строя и два других (в силу однородной природы воздействия импульса на типовые серийно выпускающиеся диски, которые, предъявляют идентичные требования к качеству электропитания).
Почему копий нужно три, а не две? Потому что в реальной жизни, очень часто, угрозы двум копиям данных оказываются статистически зависимыми в силу логической организации процедуры резервного копирования. К примеру, рассмотрим RAID1 (или дисковый массив с «зеркалированием», см. подробнее пост «технологии дисковых снапшотов»). Если вирус заражает файл на одном диске массива, сразу же происходит заражение второй копии на зеркальном диске. Аналогично, если настроена репликация, то реплика мгновенно будет также испорчена вирусом. Даже, если просто выполняется ежедневное построение полной резервной копии, она также будет заражена, если администратор за день не заметит заражение исходных данных. В целом: двух копий будет не достаточно для восстановления информации во всех случаях, когда время выявления и реакции администратора на повреждение оригинальных данных превышает период между смежными задачами по копированию/реплицированию/зеркалированию этих данных.
Для того, чтобы обеспечить еще большую статистическую независимость угроз рекомендуется записывать данные как минимум в двух различных физических форматах. К примеру, если сохранить данные на DVD (оптическая запись информации), то он не пострадает от описанного ранее электромагнитного импульса. Даже, если из строя выйдет DVD-накопитель, сами оптические носители информации сохранят ваши данные. Другими примерами статистически зависимой угрозы может являться длительное критическое повышение температуры вследствие вышедшего из строя кондиционера в серверной комнате или пожар в офисе, который, разумеется, абсолютно однородно воздействует на все копии, которые хранятся внутри офиса.
Таким образом, хранение копий в различных физических форматах имеет своей целью снизить вероятность одновременной гибели данных всех копий в силу однородного воздействия.
По сути дела, третий пункт, — хранение одной копии вне офиса, решает ту же задачу (снижение статистической зависимости угроз разным копиям данных), только через географическое распределение мест хранения. Кража или пожар в офисе могут привести к потери всех хранившихся там копии, однако пожар или кража в одном офисе не приведет к пожару или краже в другом географически обособленном офисе, что делает эти угрозы в разных офисах статистически независимыми.
А что с хранением данных в облаке? Может ли это считаться заменой бэкапа? Очевидно, нет. Это просто альтернативное место хранения данных или их резервных копий, и, кстати, хороший кандидат для внеофисного хранения резервных копий. Однако надо всегда помнить, что данные могут быть потеряны в облаке также, как и в любом другом месте.
При этом несомненным плюсом облачных провайдеров является то, что процесс резервного копирования значительно упрощается. Администратору не нужно покупать и настраивать сложное СХД или «возиться» со сменой лент. Часто облачное хранилище прозрачно расширяется по требованию клиента, то есть не имеет для него физического ограничения по размеру (ограничение для клиента скорее носит финансовый характер), что также имеет свои плюсы перед СХД, свободное место на которых может «внезапно» закончиться.
По сути облачное хранилище резервных копий копий является альтернативой лентам, так как данные из него по сравнению с локальным дисковым хранилищем извлекаются с определенной задержкой (которая зависит от ширины канала и тарифа провайдера, так как, обычно, чем ниже тариф по стоимости, тем медленнее будет скорость извлечения данных).
Всегда ли нужно жестко следовать правилу «3-2-1»? Нет, все зависит от стоимости ваших данных, с одной стороны, и критичности (стоимости потенциального ущерба) и вероятности угроз данным, с другой стороны. Любая защита не должна превышать по стоимости защищаемый объект. Поэтому, если у вас хранятся не особо ценные данные, или угрозы низко критичны или маловероятны — можно реализовывать правило «3-2-1» частично. Главное — все же составить матрицу угроз данным (то есть составить список всех возможных угроз, оценить их вероятность и критичность) и провести процесс их деактуализии (то есть у каждой угрозы либо написать в таблице либо «деактуализирована такой-то технической мерой» или «признать не актуальной с точки зрения характера бизнеса компании»). После проработки матрицы угроз, станет понятно в какой степени следует реализовывать правило 3-2-1, и какой в итоге потребуется бюджет.
Во второй части данной статьи будет рассказано как можно реализовать бэкап-правило «3-2-1» с помощью продукта Veeam Backup & Replication v7.