Бэкап понятное объяснение

Краткое содержание

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

Оглавление

1. Общее определение
2. Общее назначение
3. Виды бэкапов (как сохранять)
4. Места бэкапов (где сохранять)
5. Бэкап сайтов
6. Заключение
7. Конкретика

1. Общее определение

Бэкап в значении глагола (англ.: backup

) – это резервное копирование цифровой информации; в значении существительного (англ.: backup copy) – резервная копия этой информации.

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

2. Общее назначение

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

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

Бэкапы делаются как для веб-сайтов компаний (см. раздел 5 «Бэкап сайтов»), так и для прочих корпоративных IT-систем и данных. По сути к ним относится любая цифровая информация: внутренние базы данных (например база бухгалтерии или клиентская база), файлы и папки для внутреннего пользования (планы, отчёты, документы и проч.), внутренняя компьютерная сеть (LAN), системы аналитики, системы управления и контроля бизнес-процессов и т.д. – короче, любые данные и системы в цифровом формате.

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

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

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

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

3. Виды бэкапов (как сохранять)

Бэкап – это не всегда полное копирование информации и не всегда в том виде, в каком она присутствует в оригинале. В целом различают несколько видов бэкапов.

Полный бэкап (англ.: full backup). Копируется вся IT-система – все её файлы и структура, т.е. полностью рабочая версия. Это затратный по времени и по нагрузке на систему вид резервного копирования. Соответственно, он проводится не очень часто – еженедельно или ежемесячно, – чтобы данная процедура не нарушала ритмичность работы системы. Полный бэкап незаменим, если требуется резервная копия для быстрого восстановления и запуска системы (например сайта) с нуля. Кроме этого, полный бэкап используется для переноса сайтов с сервера на сервер (с хостинга на хостинг), а также при «реинкарнации» сайта (см. раздел 5 «Бэкап сайтов»). Но в целом, полный бэкап – это полное резервное копирование цифровой информации. А сама информация, как и цели её копирования могут быть различными.

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

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

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

Создание образа – это создание точной копии всей цифровой информационной системы, например раздела, носителя, операционной системы и проч., только не в виде реальной копии со всеми файлами, директориями и проч., а в одном файле – образе. При добавлении к образу «начинки» системы, т.е. её файлов, вся система восстанавливается согласно образу. Смысл этого вида резервирования в том, что он менее трудоёмкий, меньше нагружает систему, и файл-образ занимает небольшое дисковое пространство.

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

Какой вид резервного копирования подходит для конкретной IT-системы зависит от самой системы. Самым надежным являются полный бэкап и клонирование. Однако он и самый ресурсозатратный, т.е. может существенно тормозить работу системы во время создания резервной копии, а также занимает существенное место на диске. Кроме этого, для базовых структур многих цифровых систем, как правило, не требуется их регулярного копирования/сохранения, поскольку данные структуры неподвержены или малоподвержены изменениям (исключение – глубокое поражение вирусами или критические поломки в «железе»). Таким образом, полное резервное копирование может проводиться, например, раз в две недели, но при этом раз в неделю (а может и чаще, вплоть до ежедневного) может проводиться частичный бэкап системы: диффиринциальный, инкриментный, создание образа и т.д. Бэкап в реальном времени, может вообще происходить с минутными перерывами. Типичным примером является автосохранение файлов непосредственно в процессе работы с ними (например при написании текста в программе MS Word).

Резервные копии могут иметь разный формат. Это может быть полная копия информации – в том же формате. Например, если вы просто скопировали объёмную папку в другое место на диске или на другой носитель. Но обычно это занимает много дискового пространства, поэтому делается для не очень больших объёмов информации. В большинстве же случаев резервные данные конвертируются и хранятся в сжатом (архивном) формате, например ZIP и RAR или в специализированных форматах бэкап-фалов. В целом всё это называется архивными копиями. Они представляют собой единый файл, содержащий в себе всю зарезервированную информацию, и размер этого файла, как правило, существенно меньше, чем размер исходной информации. Создаются (архивируются) и открываются (разархивируются) бэкап-фалы специализированными программами. К ним относятся WIN ZIP (архиватор Windows), RAR, а также другие программы-архиваторы. Если речь о веб-сайте, то архивы (бэкапы) сайтов могут создаваться и затем открываться штатными возможностями системы управления сайтом (CMS). Своя система архивирования данных (бэкапов) существует, например, и у Email-клиентов, таких как The Bat, Mozilla Thunderbird и др.

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

4. Места бэкапов (где сохранять)

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

Таким образом, самым надёжным бэкапом является резервирование данных на отдельном физическом носителе (накопителе): флеш-памяти, переносном жёстком диске (HDD), DVD-диске и т.д. Также информация может сохраняться и на разных компьютерах, например рабочем и домашнем. Важно только, чтобы физические носители не попадали в руки нежелательных третьих лиц и хранились в защищённом от внешних воздействий месте – подальше от огня, воды и проч. В компании резервирование данных может выполняться на различных компьютерах в пределах локальной сети (LAN). В этом случае о безопасности, в т.ч. резервировании данных заботится уже системный администратор, под чьим контролем находится вся IT-инфраструктура компании.

Сегодня, в связи с распространением доступных облачных сервисов – файлообменников и систем типа Яндекс.Диск и Google Диск – появилась возможность хранить данные в облаке, т.е. на удаленных распределенных интернет-серверах. Эта достаточно удобно, при том, что прямо в облаке с этими данными можно и работать. Но, тем не менее, хотя доступ к данным (облачному диску) и защищён логином и паролем пользователя, информация всё равно находится не у вас «в руках», т.е. не под полным вашим контролем. Если информация очень ценная, то имеется определенный риск, что аккаунт (логин, пароль) пользователя может быть взломан злоумышленниками, и данные, соответственно, похищены или испорчены. Кроме этого, пользователь (владелец) не имеет доступа к этим данным в офлайн-режиме, т.е. без выхода в интернет.

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

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

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

9 мая 2017 г. Президентом В. Путиным подписан Указ № 203 «О Стратегии развития информационного общества в Российской Федерации на 2017 – 2030 годы», к которому прилагается и сама Стратегия. В ней уже чётко прописано, что хранение и обработка данных всеми субъектами цифровой экономики РФ должны осуществляться только в базах данных и на серверах, расположенных на территории Российской Федерации. То есть речь уже не просто об обработке персональных данных граждан, а об обязательном размещении/хранении на российских серверах любой интернет-информации, которая может иметь отношение к цифровой экономике России.

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

5. Бэкап сайтов

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

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

Резервное копирование сайта может использоваться в целом для защиты (восстановления) ресурса на том же домене и сервере (хостинге). Кроме этого, бэкап (обычно полный) может использоваться и для реинкарнации веб-ресурса. Такая необходимость возникает, например, когда поисковые системы наложили на сайт бан (полное исключение из поискового индекса; см. статью «Бан» Глоссария). В этом случае владелец может сохранить бизнес в интернете, перенеся резервную копию своего коммерческого сайта на новый домен (и обычно также на новый хостинг). Формально для поисковиков это будет уже новый сайт. Конечно, чтобы сайт опять не попал под бан и прочие поисковые санкции, владелец должен оптимизировать контент сайта – как минимум устранить негативные факторы, приведшие к бану старый сайт. Реинкарнация также может понадобиться, когда сайт не под баном, но набрал очень плохую поисковую карму, и его уже нереально поднять в поисковый ТОП обычными методами поисковой оптимизации (SEO). По сути для владельца сайта эта ситуация мало чем отличается от бана.

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

Создание резервной копии используется и при переезде сайта с сервера на сервер при смене хостинга. Также бэкап делается при клонировании сайтов, т.е. при создании зеркал. Зеркала, т.е. активные (доступные пользователю) копии сайта в сети Интернет, могут использоваться для обеспечения бесперебойной работы веб-ресурса. Это достигается за счёт того, что зеркала располагаются на различных серверах, но работают согласованно – как единый сайт. Это позволяет распределить между ними трафиковую и прочую нагрузку, что обеспечивает бесперебойную работу всей системы. Такой подход, в частности, актуален для защиты сайтов крупных компаний и организаций (например правительственных) от DoS/DDoS-атак. Да и прочие сайты, если они на слабом сервере и не распределены, могут «падать» при сильном трафике – даже целевом. Так что распределение копий сайтов на серверах через бэкапы может спасать ситуацию с точки зрения безопасности и устойчивости работы бизнес-компании или иной организации в Сети.

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

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

6. Заключение

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

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

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

7. Конкретика

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

• Настройка бэкапов IT-системы вашей компании.

• Настройка бэкапов вашего сайта.

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

• Переезд сайта на новый хостинг.

• Переезд сайта на новый домен.

• Доработка и оптимизация баз данных и прочих IT-систем.

• Доработка и оптимизация сайтов.

• Тестирование систем, в т.ч. сайтов на предмет уязвимостей.

• Антивирусная, антихакерская защита систем, в т.ч. сайтов.

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

Обращайтесь. Мы будем рады вам помочь!

Ваш SeoTemple

Опытные мелочи-4, или «Померяемся бэкапами?» / Habr

Продолжение «опытных мелочей». Предыдущие части: раз, два, три.

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

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

Для начала давайте введем и четко разделим такие понятия как архивирование и бэкап. Например вот так:

• Архивирование — это резервное копирование с ДОЛГОСРОЧНЫМ хранением данных. Процедура, когда один раз скопировали, и унесли в банковский сейф. Обращение в архив, это скорее исключение чем правило, и процедура это может быть довольно длительной (в зависимости от того где и как хранятся архивы).
• Бэкап — это резервное копирование с КРАТКОСРОЧНЫМ хранением данных. Процедура, когда копирование происходит регулярно, носители перезаписываются, есть понятие «глубина хранения». При этом доступ к бэкапу обычно должен быть максимально быстрым.

Архивирование

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

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

Бэкап

Задача бэкапа как такового — хранить свежие резервные копии, для быстрого восстановления «случайно\специально удаленного», или «сгоревшего», или «неправильно сконфигурированного». Если архивы обычно хранятся столько сколько живет организация, а иногда и дольше, то для бэкапов уже можно ввести понятие глубина хранения, т.е. время по истечение которого бэкап будет устаревать, и его можно перезаписать более свежими данными. Бэкап в целом можно разделить на две основные части: бэкап данных и бэкап систем, и отдельно стоящий бэкап содержимого систем. Последнее очень обширная и конкретная тема, сильно зависящая от того, содержимое каких именно систем вы хотите бэкапить (почтовый сервер, БД, CRM, настройки ПО и т.п.), здесь ее описывать не будем.

Бэкап систем

Бэкап систем — это когда вам нужно бэкапить не отдельные файлы, а целиком всю систему, которая может состоять из нескольких компонентов (например, спец-ПО, база SQL, файловые данные), и восстанавливать ее лучше целиком, нежели по частям. Тут все довольно просто: выбираете устраивающий вас бэкап-софт (цена, функционал, удобство) и бэкапите систему так, чтобы вы гарантированно могли восстановить ее, даже в случае полной поломки сервера. Подходят всевозможные Acronis’ы, Symantec System Recovery и т.д. Важно помнить вот что:

• вы должны УМЕТЬ восстанавливать из бэкапа. Тренируйтесь где угодно, когда угодно, но вы ДОЛЖНЫ УМЕТЬ это делать.
• продумывайте что именно вы бэкапите. Это значимо для универсальных серверов, когда, например, на одном сервере крутится БД, ваш внутрикорпоративный сайт и дополнительно прицеплен том под файловые ресурсы. В такой ситуации не стоит ради бэкапа связки «сложнонастроенный SQL + ваш сайт» бэкапить с ним заодно еще и второй файловый том в 1500 Тб. Вообще стремитесь к ситуации «одна задача — один сервер», не вешайте все-все-все на одну машину, а если уж повесили то бэкапьте его «системно».
• ваш софт должен уметь восстанавливать на другое железо, отличающееся от текущего. И вы должны это хотя бы раз попробовать!
• «системные» бэкапы, особенно систем постоянно используемых, не стоит хранить глубиной более чем неделя. Подумайте сами, зачем вам бэкап вашего контроллера домена давностью в месяц? В случае критической ситуации вам понадобится САМЫЙ свежий бэкап. А все остальные — это подстраховка, на случай если «самый свежий» по каким то причинам не отработал. Отводить на такую подстраховку больше чем 1-2 итерации, на мой взгляд нелогично и излишне расходует место.
• есть системы, которые сложно взаимосвязаны со всей инфраструктурой, и восстановить их, даже имея под рукой свежий «системный бэкап» конкретного сервера, бывает нелегко. Навскидку: Active Directory, Exchange и т.д. Выделите время, изучите документацию, и в тестовой среде, хотя бы раз — но попробуйте восстановить АБСОЛЮТНО ВСЕ! Лучше научитесь это делать в спокойной обстановке с Интернетом под рукой, чем с разъяренным начальником над головой.

Бэкап данных

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

1. По выходным делается полный бэкап всех данных. Глубина хранения 28 дней, т.е. есть четыре независимых полных бэкапа. Таким образом за последний месяц мы сможем восстановить данные за любой выходной день.
2. По рабочим дням делается дифференциальный бэкап, с глубиной хранения 14 дней. Таким образом за последние две недели мы можем восстановить данные за любой из дней.
3. в первые выходные каждого месяца, отдельно от остальных работ, делается месячный бэкап, с глубиной хранения в 12 месяцев. Это нечто среднее между бэкапом и архивом. С одной стороны срок хранения довольно большой, с другой — нередка ситуация когда нужно восстановить данные «пару месяцев назад, максимум полгода». Как вариант, можно не делать месячный бэкап отдельной работой, а просто копировать подходящий недельный.

Кроме того, я стараюсь придерживаться вот каких правил:

• использую дифференциальный, а не инкрементальный бэкап. (Если вы не знаете что это такое — обязательно прочитайте документацию, это весьма важные понятия). Мне важнее выигрыш в скорости восстановления, нежели в объеме резервных копий.
• планирую время бэкапа так чтобы успевать до утра. Если бэкап выполняется дольше — разбиваю его на несколько работ, несколько серверов, или поднимаю вопрос про другое, более скоростное, оборудование.
• в расписании бэкапа стараюсь придерживаться промежутков связанных с неделями(7 дней, 28 дней и т.д.) и не привязываться к «первым\последним дням месяца». Неделя — довольно постоянная величина, 7 дней и в большинстве случаев суббота, воскресенье — это выходные.
• использую диски, а не ленты. Мне не нравится дорогостоящий посредник-стример между данными в бэкапе и данными в файлохранилище. Если он по каким то причинам не работает, то надолго нарушается вся система бэкапа. Если использовать жесткие диски, то этого можно избежать.
• стараюсь чтобы логически самостоятельная часть данных лежала в отдельном бэкапе. Например, если говорить про Symantec Backup Exec, то одна работа=одна media. Очень не люблю ситуацию, когда одна работа «размазана» по нескольким файлам. Это не только вносит сумбур в систему, но и в случае случайного затирани одного из файлов («рука дрогнула») наносит вред не только одной работе но и всем соседним.
• в обязательном порядке использую софт с уведомлениями по почте. Если это самописный скрипт — никто не мешает дописать кусочек, который будет проверять хотя бы наличие нового бэкапа, его размера и слать данные по почте. Это сильно экономит время в мониторинге бэкапа.

Кроме всего прочего модно также использовать т.н. «моментальные» бэкапы, небольшой глубины (1-2 дня) а-ля служба VSS в Windows, когда пользователи сами могу выбирать что восстановить из последних версий документа. Это очень помогает, когда пользователь утром отредактировал документ, а в обед его удалил и прсит восстановить утренний вариант.
Также можно использовать DFS систему в роли постоянного онлайн бэкапа, но это стоит описать в отдельном посте, что я позже и сделаю.

Продолжение следует.

P.S. Напомню, я не устанавливаю правил, а делюсь своим опытом, опытом НЕуниверсальным, полученным в небольших организациях (30-500 ПК). Если у вас принято делать иначе — с удовольствие прочитаю об этом в комментариях.

разрушаем мифы в честь праздника / ПСБ corporate blog / Habr

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

Этой тематикой я занимаюсь уже почти 20 лет, из них последние 2 года – в Промсвязьбанке. В самом начале практики делал резервное копирование практически вручную, скриптами, которые просто копировали файлы. Потом в Windows появились удобные инструменты: утилита Robocopy для подготовки файлов и NT Backup для копирования. А уже потом пришло время специализированного ПО, в первую очередь Veritas Backup Exec, который сейчас называется Symantec Backup Exec. Так что с бэкапами знаком давно.

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

Самое же типичное обращение к бэкапам – это восстановление сохраненной копии баз данных для развертывания различных тестовых систем, клонов для разработчиков.

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

Миф 1. Бэкап давно уже всего лишь мелкая функция внутри систем безопасности или хранения

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

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

Миф 2. Когда есть RAID, бэкап уже не нужен

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

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

Миф 3. Бэкап – это то, что делается раз в месяц.

Частота резервного копирования – это настраиваемый параметр, в первую очередь зависящий от требований к системе резервного копирования. Вполне реально найти данные, которые практически никогда не меняются и особо не важны, их потеря не будет критичной для компании.
Их, действительно, можно бэкапить раз в месяц и даже реже. А вот более критичные данные сохраняются чаще, в зависимости от показателя RPO (Recovery point objrective), задающего допустимую потерю данных. Это может быть раз в неделю, раз в сутки или даже несколько раз в час. У нас это журналы транзакций из СУБД.

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

Миф 4. Объем копий беспрестанно растет и занимает любое выделенное пространство полностью

Резервные копии имеют ограниченный срок хранения. Нет смысла, например, складировать в течение года все 365 ежедневных бэкапов. Как правило допустимо хранить ежедневные копии 2 недели, после чего замещаются свежими, а на долговременном хранении остается та версия, что была сделана первой в месяце. Она, в свою очередь, тоже хранится определенное время – у каждой копии есть время жизни.

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

Миф 5. Начался бэкап – всё повисло

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

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

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

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

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

Миф 6. Запустил систему резервного копирования – вот тебе и отказоустойчивость

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

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

Миф 7. Настроил один раз бэкап, проверил что работает. Остается только логи смотреть

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

И немного о работе сисадмина

В ручном режиме никто данные уже давно не копирует. Современные СРК умеют бэкапить практически всё, стоит только как следует его настроить. Если добавился новый сервер – прописать политики: выбрать контент, который будет бэкапиться, указать параметры хранения, и применить расписание.

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

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

Обзор UrBackup, BackupPC, AMANDA / Southbridge corporate blog / Habr

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

Обзор UrBackup.

По просьбе участника VGusev2007 добавляю обзор UrBackup, клиент-серверной системы для резервного копирования. Она позволяет создавать полные и инкрементальные резервные копии, умеет работать со снимками устройств (Win only?), а также умеет создавать файловые резервные копии. Клиент может находиться как в одной сети с сервером, так и подключаться через Internet. Заявлено отслеживание изменений, что позволяет быстро найти отличия между резервными копиями. Также имеется поддержка дедупликации хранения данных на стороне сервера, что позволяет экономить занимаемое место. Сетевые соединения шифруются, также имеется web-интерфейс для управления сервером. Давайте посмотрим, на что она способна:

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

Время работы:

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

Время работы:

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

Обзор BackupPC

По просьбе участника vanzhiganov добавляю обзор BackupPC. Данное ПО устанавливается на сервер хранения резервных копий, написано на perl, работает поверх различных средств резервного копирования — в первую очередь rsync, tar. В качестве транспорта используется ssh и smb, также в наличии есть web-интерфейс на основе cgi (разворачивается поверх apache). В web-интерфейсе есть обширный список настроек. Из особенностей — наличие возможности задания минимального времени между резервными копиями, а также периода, в течение которого резервные копии не будут создаваться. При выборе файловой системы для сервера резервного копирования надо следить за поддержкой жестких ссылок. Таким образом, файловую систему для хранилища не разобьешь на точки монтирования. В целом, достаточно приятное впечатление, давайте посмотрим, на что способно это ПО:

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

Если же использовать полные резервные копии и tar:

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

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

В целом видно небольшое преимущество по скорости у rsync, также rsync экономнее работает с сетью. Отчасти это может быть скомпенсировано меньшим использованием cpu с tar в качестве программы для создания резервных копий. Другим преимуществом rsync является работа с инкрементальными копиями. Размер репозитория при создании полных резервных копий одинаков, составляет 16 гб, в случае инкрементальных копий — 14 гб за один прогон, что означает работающую дедупликацию.

Обзор AMANDA

По просьбе участника oller добавляю тесты AMANDA,

Результаты тестового прогона с tar в качестве архиватора и активацией сжатия таковы:

Программа полностью загружает одно процессорное ядро, но из-за ограниченного по iops диска на стороне сервера хранения резервных копий не может развить большую скорость передачи данных. В целом, настройка доставила чуть больше хлопот, чем у остальных участников, поскольку автор программы не использует в качестве транспорта ssh, а реализует схожую схему с ключами, создавая и поддерживая полноценную CA. Есть возможность широко ограничить клиента и сервер резервного копирования: например, если они не могут полностью доверять друг другу, то можно, как вариант, запретить инициирование восстановления резервной копии со стороны сервера, задавая значение соответствующей переменной в ноль в файле настроек. Есть возможность подключить web-интерфейс для управления, но в целом настроенную систему можно автоматизировать полностью с помощью небольших скриптов на bash (или SCM, к примеру ansible). Существует несколько нетривиальная система настройки хранилища, что, по всей видимости, связано с поддержкой обширного списка различных устройств для хранения данных (кассеты LTO, жесткие диски и т.п.). Также стоит отметить, что из всех программ, рассмотренных в этой статье, AMANDA — единственная, сумевшая обнаружить переименование каталога. Размер репозитория при одном прогоне составил 13 гб.

Анонс

Резервное копирование, часть 1: Зачем нужно резервное копирование, обзор методов, технологий
Резервное копирование, часть 2: Обзор и тестирование rsync-based средств резервного копирования
Резервное копирование, часть 3: Обзор и тестирование duplicity, duplicati
Резервное копирование, часть 4: Обзор и тестирование zbackup, restic, borgbackup
Резервное копирование, часть 5: Тестирование bacula и veeam backup for linux
Резервное копирование, часть 6: Сравнение средств резервного копирования
Резервное копирование, часть 7: Выводы

Backup — дело тонкое / Habr

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

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

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

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

Backup своего большого веб-проекта

Большой проект очень не просто забакапить надёжно — так, чтобы после восстановления из бакапа он гарантированно продолжил работать и не возникло никаких проблем (кроме отсутствия новых данных, которые были добавлены после последнего бакапа, конечно). Дело в том, что и файлы на диске и база данных далеко не всегда находятся в «целостном» (consistent) состоянии. Выполняются какие-то транзакции в базе (которые далеко не всегда явно оформлены как SQL-транзакции, кстати), создаются временные файлы, пишутся логи… Причём в большом проекте зачастую много других «точек входа» помимо HTTP: обработка входящих писем, RPC-запросов, cron-задачи, работают разные TCP/UDP сервисы. Застать всю эту махину в целостном состоянии, да ещё и продержать в нём всё то время, что выполняется бакап — задача для внешней софтины просто невыполнимая!

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

Но это привело к новой проблеме — ведь бакап дело не быстрое, особенно бакап большой базы данных… а если проект надолго блокировать раз в сутки, то наши пользователи нам за это спасибо точно не скажут. Эту проблему мы решили реорганизацией базы данных таким образом, что все таблицы были разделены на два типа: статические и динамические. Со «статическими» таблицами выполняются только SQL-запросы SELECT и INSERT, а «динамические» могут меняться как угодно. Разумеется, все объёмные данные были вынесены в статические таблицы. Это позволило сократить время блокирования проекта для бакапа до нескольких секунд: для архивирования (tar-ом, без сжатия) файлов проекта, создания дампа динамических таблиц, и запоминания id последней записи в статических таблицах.

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

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

Backup обычного dedicated сервера

Обдумав свои требования к софту для бакапа сервера, я пришёл к следующему списку:

• Софт для бакапа должен быть простым и надёжным. Зависимость количества багов от размера софта все знают, и мне только багов в бакапах нехватало для полного счастья!
• При бакапе сервера целиком невозможно учесть все нюансы установленных на нём проектов и обеспечить их гарантированную целостность после восстановления из бакапа. Поэтому описанный ниже подход используется не вместо, а вместе с описанным выше бакапом конкретных проектов. Но, тем не менее, есть вещи которые необходимо обеспечить и при бакапе сервера — например, целостность базы данных (она может не быть целостной с точки зрения конкретного проекта, но она должна быть целостной с точки зрения MySQL-сервера).
• Бакап должен выполняться быстро, чтобы не мешать серверу выполнять свою основную функцию. (На сервере одного знакомого админа я как-то обнаружил, что его cron-задача архивирующая винт раз в сутки в .tar.bz2 выполняется два часа, причём ничего другого в это время на сервере делать практически невозможно!) В частности, с учётом предыдущего пункта, это означает, что блокировать базу данных нужно не на всё время бакапа сервера, а только на время бакапа файлов самой базы данных.
• Формат файлов. Ставить такую критичную вещь как бакапы в зависимость от нестандартных форматов файлов очень не хотелось. Стандартных утилит более чем достаточно для архивирования и шифрования бакапов (например tar + gzip + gpg).
• Система должна позволять достаточно гибко обрабатывать бакапы — шифровать, заливать на другие сервера, etc.
• Интерфейс должен быть достаточно информативным для отлаживания и настройки бакапов, но при этом не должен спамить меня раз в сутки письмами с каждого сервера «всё в порядке, бакап сделан», я хочу получать письмо только если произошла ошибка.

powerbackup

Может я не там искал, но мне не удалось найти софт, соответствующий этим требованиям. Поэтому я его написал сам: powerbackup. 🙂 Получился небольшой и простой sh-скрипт (70 строк, 2 KB), полностью отвечающий описанным выше требованиям и решивший для меня проблему бакапа серверов.

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

1. Общая задача «бакап сервера» разделяется на несколько подзадач, например: бакап настроек сервера, бакап базы сервера, бакап домашних каталогов пользователей.
2. Создание бакапа разделено на два этапа: подготовка файла (инкрементально через tar) и его архивация (gzip). И для каждой задачи можно указать индивидуальные hook-и для этих этапов. Например, задача бакапа базы перехватывает первый этап, чтобы заблокировать MySQL на время архивации файлов в /var/lib/mysql/. А задача бакапа пользовательских каталогов может перехватить второй этап, чтобы заменить сжатие через gzip на шифрование через gpg и заливание файла через scp.

Более детальные примеры настройки есть на сайте.

Лицензия, как обычно, public domain.

Backup или Бэкап, всей системы, резервное копирование.

Backup или Бэкап, всей системы, резервное копирование.

Эта статья пойдет о создании резервной копии вашей операционной системы по другому Бэкап или на английском Backup. Поговорим о двух видах операционных систем, а точнее Windows и Linux.

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

Вначале немного болтологии.

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

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

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

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

Как поступаю я.

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

Если система работает так как надо, то можно подготовить бэкап сейчас. В любом случае бэкап пригодится.

Предупреждение и нюансы.

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

Если любите хранить все на рабочем столе и в стандартных папках то перенесите их расположение, про перенос читайте подробно в этой статье.

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

В моем случае под систему определен целый SSD диск. Периодически я делаю резервную копию с этого диска.

Backup в системе windows средствами самой системы.

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

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

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

Принцип настройки данного способа одинаков и схож у всех семейств windows от 7 до 10 версии. Рассмотрим основные шаги по настройке бэкапа на примере windows 10.

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

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

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

Далее вам предложат два варианта:

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

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

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

Я выбираю второй вариант, указываю «диск (С:)» и дополнительно нужные мне папки на других разделах.

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

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

Ну и в конце нажимаем сохранить и создать архив, система сделает ваш первый архив.

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

выбираем пункт Восстановление системы

Теперь выбираем Диагностика, Дополнительные параметры, Восстановить из образа системы.

Затем выбираем образ системы или используем последний созданный образ системы и восстанавливаем нажатием далее и ОК.

Backup в Linux.

Резервное копирование в системе linux расскажу на примере программы Timeshift. Эта программа так же настраивается на создание резервной копии системы по времени, можно указать файлы и папки дополнительно для резервного копирования.

При первом запуске вы увидите следующее окно

Тип снимков как правило оставляем по умолчанию и переходим в окно «место», указываем раздел диска в котором будем хранить резервную копию

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

Во вкладке пользователи указываем файлы каких пользователей включать в бэкап

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

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

Чтоб восстановить систему из резервной копии вам необходимо будет загрузится с загрузочного носителя с Live системой Linux. Подробности настройки и загрузки с диска или флешки в этой статье.

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

Программа Fsarchiver — делает копию раздела Linux.

По умолчанию эта программа есть в репозитории Debian 10 и многих других системах, устанавливаем ее

Установив этот пакет вы сможете использовать программу только при помощи терминала. Поэтому ставим графический интерфейс этой программы.

В репозитории его нет, называется он qt4-fsarchiver.

Скачать его можно по этой ссылке в разделе файлы, выбираем в deb packages — нужный нам пакет, под нашу систему.

После устанавливаем скаченный пакет и запускаем.

Далее думаю с этой программой вам не составит труда разобраться.

В Debian 10 пакет qt4-fsarchiver не устанавливается из за конфликтов зависимостей. Разработчики отказались от поддержки qt4.

В Debian 9 устанавливал deb пакет от linux mint 17 и 15, все работало.

Есть еще программа Systemback — которая позволит создать не только резервную копию, но и live сборку linux на основе вашей операционной системы, работающей в данный момент.

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

Если есть желание то можете скачать и установить на официальном сайте.

Backup средствами сторонних программ.

В качестве сторонних программ можно использовать программу Clonzilla или Acronis true image. Эти программы записываются на загрузочный носитель и загрузившись с него вы делаете копию своего диска.

В последствии вы можете восстановить эту копию даже на другой диск.

Я делаю такую копию один раз когда полностью настроил свой компьютер. В случае краха системы я просто потом восстанавливаю систему из этой копии.

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

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

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

Всем Удачи!

Бэкап — это… Что такое Бэкап?

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

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

Цель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Борьба:

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

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

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

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

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

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

См. также

Ссылки

Wikimedia Foundation. 2010.