Бэкап что это такое

Бэкап понятное объяснение и примеры бекапов

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

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

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 на отдельный раздел.

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

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

Всем Удачи!

Как сделать бэкап любого сайта

Закон Мёрфи гласит: если плохое может случиться, оно случится. Бутерброд всегда падает маслом вниз. Сайты тоже падают.

Чтобы не пострадать от закона Мёрфи, делайте бэкапы. Мы собрали три способа сделать резервную копию сайта (на WordPress и не только): через FileZilla, панели управления или сервисы для бэкапов.

Что такое бэкап сайта и зачем он нужен

Бэкап — это резервная копия данных. Она нужна на случай, если с оригиналом что-то случится. Кнопка «Удалить» попадёт под горячую руку, сгорит компьютер или наступит армагеддон — не страшно. Если есть копия, потерянные данные можно быстро восстановить.

Любой ценной информации нужны бэкапы: семейным фото, почтовой переписке, рабочим документам. Но особенно — сайтам. И на это есть три причины.

1. Ненадёжный хостинг. Сайт — это набор файлов, который хранится на сервере. Серверы, как и любые компьютеры, ломаются. Сотрудники, которые следят за их работой, ошибаются. Программное обеспечение даёт сбой. Любая из этих проблем может стоить вам сайта.
2. Злоумышленники. Истории про конкурентов, которые проникли на сайт и на главной странице написали «Васька дурак» или просто всё удалили, конечно, редкость. Гораздо чаще сайтам вредят вирусы. И один из способов от них избавиться — восстановить чистую резервную копию.
3. Наше несовершенство. Больше, чем ненадёжный хостинг и злоумышленники, сайтам угрожают их владельцы. «Случайно удалил», «нажал не туда», «переделал, а теперь хочу всё вернуть» — люди несовершенны, всем нам свойственно ошибаться. Сайт без бэкапа не прощает ошибок.

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

Почему никто не делает бэкапы

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

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

«В студенчестве я подрабатывал в одной фирме, и у неё был сайт. Тогда карты и справочники не были распространены, и на сайт за справкой каждый день заходило много пользователей. А у меня ещё было недостаточно навыков в "этих ваших линуксах", и я случайно удалил половину разделов сайта, а бэкапа не было. Хуже всего то, что сделал я это 31 декабря и не заметил. Все каникулы сайт лежал. Я очень сильно пожалел!»

Иван Литвинцев, проджект-менеджер Vepp

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

Экономят на ресурсах. Бэкап — это копия всех файлов сайта. Она занимает столько же места, сколько оригинал: сайт «весит» 1Гб, бэкап будет меньше, но ненамного. А ещё сам процесс копирования отнимает ресурсы. Если запустить бэкап в пик посещаемости, сайт начнёт работать медленнее. То есть причина не надуманная, для создания резервных копий и правда нужны ресурсы.

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

Как сделать бэкап сайта

Проблему с бэкапами можно решить по-разному.

Бесплатно или почти бесплатно

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

Чтобы сэкономить на месте, можно сохранять копии на компьютер или ноутбук. Лучше использовать облачное хранилище — Google Диск, Яндекс.Диск, Dropbox. Если хранилище уже оплачено для других задач, то его просто можно приспособить для бэкапов. Если нет — оплатить начальный тариф или использовать «приветственные» гигабайты.

Чтобы сэкономить на настройке, воспользуйтесь бесплатными сервисами.

FileZilla и phpMyAdmin
Это бесплатные сервисы, их может скачать любой. FileZilla управляет файлами, phpMyAdmin — базами данных. Да-да, файлы и БД придётся копировать по отдельности. Способ точно не самый простой и не самый надёжный (придётся самому контролировать актуальность бэкапов). Зато самый доступный: вообще ни за что не надо платить.

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

Просто или почти просто

Описанные выше способы всё-таки потребуют некоторого участия. Если вы не готовы вникать в инструкции, но готовы заплатить — вот вам пара простых вариантов.

Бэкапы своими руками для чайников / Habr

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

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

Задача

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

Дано

• VPS на базе Centos 5 x86_64.
• Панель управления ISP Manager. Стандартные средства ISP Manager не устраивают.
• Свободного места на сервере очень мало.

Цель

Получить архивы файлов и БД на сервере в определенной папке. Архивы должны быть доступны по http-протоколу.

Решение

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

Бэкап MySQL
Делает дампы всех БД, доступных для указанного пользователя.

#!/bin/sh
 
 # ---- Константы --------------------------------------
 # Папка, куда складываем бекапы
 BACKUP_DIR="/var/www/wscms/data/www/site.ru/backup/"
 # Имя файла бекапа
 BACKUP_FILE="sql.tar"
 # Пользователь, владелец файла с бекапами
 USER="wscms"
 # Папка для временных дампов MySQL
 MDIR="mysql/"
 # Сервер БД MySQL
 MHOST="localhost"
 # MYSQL root пользователь
 MUSER="root"
 # MYSQL root пароль
 MPASS="***************"
 # Поставьте "-zcf" если хотите сжимать данные или "-cf" в противном случае
 PARAMS="-cf"
 
 #--- Служебные переменные --------------------------
 # Путь к mysql.
 MYSQL="$(which mysql)"
 # Путь к mysqldump
 MYSQLDUMP="$(which mysqldump)"
 # Путь к tar
 TAR="$(which tar)"
 # Путь к chown
 CHOWN="$(which chown)"
 # Путь к RM
 RM="$(which rm)"
 # Путь к MKDIR
 MKDIR="$(which mkdir)"
 
 # ---- Получаем список баз данных
 DBS="$($MYSQL -u $MUSER -h $MHOST -p$MPASS -Bse 'show databases')"
 
 # ---- Чистим папку с дампами на случай, если она уже существовала
 $RM -rf $BACKUP_DIR$MDIR
 # ---- Создаем папку для дампов
 $MKDIR -p $BACKUP_DIR$MDIR
 
 # ---- Делаем дампы найденых баз. Старые дампы замещаются
 for db in $DBS
 do
 FILE=$BACKUP_DIR$MDIR$db.sql
 $MYSQLDUMP -u $MUSER -h $MHOST -p$MPASS $db > $FILE
 done
 
 # ---- Архивируем файлы
 $TAR $PARAMS $BACKUP_DIR$BACKUP_FILE $BACKUP_DIR$MDIR
 
 # ---- Удаляем уже не нужную нам папку с MySQL дампами
 $RM -rf $BACKUP_DIR$MDIR
 
 $CHOWN $USER $BACKUP_DIR
 $CHOWN $USER $BACKUP_DIR$BACKUP_FILE
 exit 0

Бэкап файлов

#!/bin/sh
 
 # ---- Константы --------------------------------------
 # Папка, куда складываем бекапы
 BACKUP_DIR="/var/www/wscms/data/www/site.ru/backup/"
 # Расширение файла бекапа
 EXT=".tar"
 # Директория, в которой лежат аккаунты
 MAIN_DIR="/var/www/"
 # Директория, в которой лежат сайты аккаунтов
 DATA_DIR="/data/www/"
 # Пользователь, владелец файла с бекапами
 USER="wscms"
 # Поставьте "-zcf" если хотите сжимать данные или "-cf" в противном случае
 # используйте u для добавления только новых файлов
 PARAMS="-cf"
 
 #--- Служебные переменные --------------------------
 # Путь к tar
 TAR="$(which tar)"
 # Путь к chown
 CHOWN="$(which chown)"
 RM="$(which rm)"
 MKDIR="$(which mkdir)"
 
 # ---- Создаем папку для дампов
 $MKDIR -p $BACKUP_DIR
 $CHOWN -R $USER $BACKUP_DIR
 
 # ---- Для всех пользователей панели
 for DIR in $(/usr/local/ispmgr/sbin/mgrctl -m ispmgr user | cut -d' ' -f1 | sed s/name=//)
 do
 # ---- Архивируем файлы
 $TAR $PARAMS $BACKUP_DIR$DIR$EXT $MAIN_DIR$DIR$DATA_DIR
 $CHOWN $USER $BACKUP_DIR$DIR$EXT
 done
 
 $CHOWN -R $USER $BACKUP_DIR
 exit 0

Добавляем в CRON от root-пользователя
/bin/sh /backup/backup.sh
/bin/sh /backup/sql.sh
Ставим нужное нам расписание

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

Теперь мы можем делать с ними все что угодно: либо на стороннем сервере в другом ДЦ забирать их с помощью wget, либо (как это реализовано у меня) с помощью несложного windows-приложения, загруженного в планировщик, ежедневно скачивать бэкапы на локальную машину.

В целях безопасности в папку site.ru/backup/ советую положить следующий .htaccess
Order Deny,Allow
Deny from all
Allow from Ваш.IP.Адрес, IP.Адрес.ВПС.Если.Используете.wget

Удачи Вам, и не теряйте свои данные.

Бэкап – что это такое? Резервное копирование файлов :: SYL.ru

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

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

Общие сведения

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

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

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

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

Когда делать резервное копирование

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

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

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

Где можно сохранять резервную копию

Что это такое - бэкап, мы уже поняли, тогда следует разобраться, куда можно делать резервное сохранение? Как правило, есть два наиболее надежных способа, которые позволят максимально сохранить данные.

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

Запись на внешний диск

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

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

Флеш-накопитель

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

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

Компакт-диски

Несмотря на то, что данные устройства уже вышли из моды, все равно в некоторых случаях они незаменимы. Не нужно использовать варианты с 700 Мб. Диск с памятью почти в 9 Гб вполне может быть хорошим носителем. Однако следует заметить, что эти устройства нужно защищать от перепада температур, дефектов, а также солнечного света. Если говорить о надежности и вместимости, то следует выбирать диски DVD. Такие болванки вполне надежные.

Также хорошо подходят CD диски, однако их максимальная емкость 700 Мб. На данный момент это смешной показатель. Очень вместительными являются диски blu-ray. Они способны вмещать более 30 Гб информации. Однако приводы для того, чтобы их читать и записывать на них, установлены не в каждом устройстве. Более того, они максимально чувствительные к механическим воздействиям.

Облако

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

Наиболее популярными сейчас облаками являются сервисы Dropbox, Google и "Яндекс". Нужно заметить, что второй вариант бесплатно выдает пользователем 15 Гб места, чего будет максимально хватать для домашнего использования.

Как создать резервную копию Windows

Если человек до этого работал с Windows 98, то он прекрасно помнит о сбоях системы. Операционка была, в принципе, неплохая, однако при несовместимости каких-либо утилит на 100% всегда было ясно, что системная ошибка приведет к переустановке операционной системы. Однако в новых версиях производитель все же предусмотрел бэкап Windows. В Vista, а также версиях 7 и 8 данная функция была доведена практически до отличного состояния.

На примере рассмотрим создание бэкапа операционной системы Windows 7. Сделать его можно очень просто. Следует зайти в панель управления, там найти пункт "Архивация и восстановление". Следует нажать на меню левой клавишей мышки и перейти в подпункт "Создание образа". Снова откроется всплывающее окно, в котором нужно выбрать любой из трех вариантов создания резервной копии. Сделать это можно на болванку, залить в сеть или воспользоваться жестким диском. Следует поставить галочку напротив того пункта, куда человек собрался проводить бэкап. После этого следует сохранить настройки. Заметить нужно, что, если соединение с интернетом плохое, а также нестабильное, то попытка сохранить в сеть операционную систему выйдет неудачной.

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

Мобильные устройства

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

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

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

Что потребуется для резервного сохранения

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

ТОП-15 Программ для Бэкапа Данных

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

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

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

После этого кликаете по кнопке «Далее» и наблюдаете за процессом установки.

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

Кликнув по ней, вы произведете запуск приложения.

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

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

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

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

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

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

В пункте «Расписание» вы сможете задать время произведения резервного копирования.

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

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

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

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

Скачать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UPDATE

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

Автоматический бэкап | Что такое копирование данных

Бэкап (backup) — это создание резервной копии существующих файлов, папок и других данных на компьютере. Бэкап можно делать вручную, но лучше использовать автоматическое резервное копирование компьютера с помощью специальных программ, например, Handy Backup. Регулярный бэкап файлов, папок и другой информации Решение Handy Backup позволяет настроить задачи резервного копирования по расписанию (auto backup) в определённое время и с определённым точно указанным интервалом повторного запуска, а также по определённому системному событию, например, при входе в ОС. Автоматический бэкап Все функции бэкапа данных в Handy Backup реализованы с помощью плагинов — специальных инструментов, осуществляющих бэкап данных определённого типа. На нашем сайте вы можете подробнее прочесть, что такое бэкап файлов, папок, баз данных, библиотек, образов диска и др. Дополнительные функции создания копии данных С помощью дополнительных встроенных инструментов Handy Backup вы можете зашифровать копии данных, сжать их в архив, сделать частичный бекап файлов вместо полного, поставить метку времени создания копии данных и т.д. Рекомендуемое решение для автоматического бэкапа данных Версия 8.1.2 от 21 февраля 2020 . 106 MB Программа резервного копирования Handy Backup. 2900 RUB за лицензию Программа для бэкапа папок и файлов, создания образов диска. Бесплатный пробный период в течение 30 дней! Бэкап файлов и папок Автоматический бэкап файлов в Handy Backup позволяет сохранять данные из системных и пользовательских папок, библиотек Windows, файлы приложений, использовать файловые фильтры и т.д. Можно использовать файловые фильтры по маске имени и типа для бэкапа. Автоматический бэкап почтовых сервисов С помощью Handy Backup вы можете выполнить бэкап почты Gmail, Outlook, папок и файлов любого локального клиента (Thunderbird, The Bat! и т.д.), сделать резервную копию почты с Web-сервиса по IMAP или произвести копирование данных Exchange Server. Бэкап баз данных Резервное копирование баз данных в Handy Backup включает в себя автоматический бэкап 1С, MS SQL Server, MySQL, MariaDB, PostgreSQL, Oracle, Lotus Notes/Domino, IBM DB2, а также любых баз данных через ODBC-драйвер с помощью универсального плагина Database. Копирование данных виртуальных машин Образы дисков виртуальных машин могут быть скопированы Handy Backup как файлы, а также при помощи специализированных плагинов Hyper-V backup, VMware Workstation. При этом копия Handy Backup может как устанавливаться на виртуальную машину, так и использоваться "извне". Специальные типы данных В Handy Backup предусмотрено создание образов жесткого диска (включая загрузочные системные диски) и отдельных разделов диска, а также копирование статического и динамического контента Web-сайтов и реестра Windows. Облачные сервисы С помощью Handy Backup вы можете выполнять бэкап на облака, такие как Яндекс и Google Диски, OneDrive/OneDrive для бизнеса, Amazon S3, Mail.ru Hotbox/Icebox и другие. Помимо этого, вы можете установить соединение с любым облачным хранилищем, поддерживающих WebDAV. Сетевые хранилища (Network Backup) Помимо сетевых (shared) дисков, программа Handy Backup работает с папками общего доступа на сетевых хранилищах информации (бэкап на NAS), а также позволяет выполнять копирование на серверы FTP, SFTP и FTPS как в локальной сети, так и через Интернет. Локальные диски и внешние устройства USB Вы можете сохранить данные на локальном диске или прикреплённом (mapped) диске в любой папке. Для внешних USB дисков предусмотрен режим запуска задачи при подключении диска к компьютеру. Вы можете также сохранять данные на других компьютерах в локальной сети*. * Данная функция доступна только в сетевом решении Handy Backup Server Network. В Handy Backup все задачи создаются и управляются с помощью простого графического интерфейса. Чтобы настроить автоматический бэкап, вам нужно создать новую задачу и указать её необходимые параметры в соответствии с вашими предпочтениями. Подробнее о создании задачи бэкапа ознакомиться в Руководстве пользователя. Бэкап файлов, дисков и любой другой информации с Handy Backup – надёжное и удобное средство автоматической защиты ваших данных! Попробуйте бесплатно 30-дневную полную версию программы!

Теория и практика бэкапов с Borg / Флант corporate blog / Habr

К нашему огромному удивлению на хабре не оказалось ни одного материала про замечательный Open Source-инструмент для резервного копирования данных ­— Borg (не путать с одноимённым прародителем Kubernetes!). Поскольку уже более года мы с удовольствием используем его в production, в этой статье я поделюсь накопленными у нас «впечатлениями» о Borg.

Предыстория: опыт с Bacula и Bareos

В 2017 году мы устали от Bacula и Bareos, которые использовали с самого начала своей деятельности (т.е. около 9 лет в production на тот момент). Почему? За время эксплуатации у нас накопилось немало недовольства:

• Зависает SD (Storage Daemon). Если у вас настроена параллельность, то обслуживание SD усложняется, а его зависание блокирует дальнейшие бэкапы по расписанию и возможность восстановления.
• Нужно генерировать конфиги и клиенту, и директору. Даже если автоматизировать это (в нашем случае в разное время применялись и Chef, и Ansible, и своя разработка), нужно мониторить, что директор после своего reload’а на самом деле подхватил конфиг. Это отслеживается только в выводе команды reload и вызове messages после (чтобы получить сам текст ошибки).
• Расписание бэкапов. Разработчики Bacula решили пойти собственным путём и написали свой формат расписаний, который не получится просто распарсить или конвертировать в другой. Вот примеры стандартных расписаний бэкапов в наших старых инсталяциях:
  • Ежедневный полный бэкап по средам и инкрементальные в остальные дни:
    Run = Level=Full Pool="Foobar-low7" wed at 18:00
Run = Level=Incremental Pool="Foobar-low7" at 18:00
  • Полный бэкап wal-файлов 2 раза в месяц и инкремент каждый час:
    Run = Level=Full FullPool=CustomerWALPool 1st fri at 01:45
Run = Level=Full FullPool=CustomerWALPool 3rd fri at 01:45
Run = Level=Incremental FullPool=CustomerWALPool IncrementalPool=CustomerWALPool on hourly
  • Сгенерированных schedule на все случаи жизни (в разные дни недели каждые 2 часа) у нас получилось примерно 1665… из-за чего Bacula/Bareos периодически сходили с ума.
• У bacula-fd (и bareos-fd) на каталогах с большим количеством данных (скажем, 40 ТБ, из которых на 35 ТБ приходятся крупные файлы [100+ Мб], а на оставшиеся 5 Тб — мелкие [от 1 Кб до 100 Мб]) начинается медленная утечка памяти, что на production ну совсем неприятная ситуация.

• На бэкапах с большим количеством файлов Bacula и Bareos очень сильно зависят от производительности используемой СУБД. На каких она дисках? Насколько мастерски вы умеете её тюнить под эти специфичные нужды? А в базе, между прочим, создаётся одна(!) непартицируемая таблица со списком всех файлов во всех бэкапах и вторая — со списком всех путей во всех бэкапах. Если вы не готовы выделить хотя бы 8 Гб RAM под базу + 40 Гб SSD для вашего бэкап-сервера — сразу готовьтесь к тормозам.
• Зависимость от БД достойна ещё одного пункта. Bacula/Bareos на каждый файл спрашивают директора, был ли уже такой файл. Директор, конечно, лезет в БД, в те самые огромные таблицы… Получается, что резервное копирование можно заблокировать просто тем фактом, что одновременно запустились несколько тяжёлых бэкапов — даже если diff’а там на несколько мегабайт.

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

Bacula/Bareos прекрасно работают с небольшим количеством (10-30) однородных job’ов. Сломалось какая-то мелочь раз в неделю? Ничего страшного: отдали задачу дежурному (или другому инженеру) — починили. Однако у нас есть проекты, где количество job’ов исчисляется сотнями, а количество файлов в них — сотнями тысяч. В итоге, 5 минут в неделю на починку бэкапа (не считая нескольких часов настройки до этого) начали приумножаться. Всё это привело к тому, что 2 часа в день нужно было заниматься починкой бэкапов во всех проектах, потому что буквально везде что-то по мелочи или серьёзно ломалось.

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

Borg как новый путь

Поиски других Open Source-вариантов были размазаны во времени, поэтому сложно оценить общие затраты, но в один прекрасный момент (в прошлом году) наше внимание устремилось к «виновнику торжества» — BorgBackup (или просто Borg). Отчасти тому способствовал реальный опыт его использования одним из наших инженеров (на предыдущем месте работы).

Borg написан на Python (необходима версия >= 3.4.0), а требовательный к производительности код (сжатие, шифрование и т.п.) реализован на C/Cython. Распространяется на условиях свободной лицензии BSD (3-clause). Поддерживает множество платформ включая Linux, *BSD, macOS, а также на экспериментальном уровне Cygwin и Linux Subsystem of Windows 10. Для инсталляции BorgBackup доступны пакеты для популярных Linux-дистрибутивов и других ОС, а также исходники, устанавливаемые в том числе и через pip, — более подробную информацию об этом можно найти в документации проекта.

Чем же Borg нас так сильно подкупил? Вот его основные достоинства:

Переход на Borg начал осуществляться медленно, на небольших проектах. По началу это были простые скрипты в cron, которые каждый день делали своё дело. Всё так продолжалось около полугода. За это время нам приходилось много раз доставать бэкапы… и оказалось, что Borg не пришлось чинить буквально совсем! Почему? Потому что тут работает простой принцип: «Чем проще механизм, тем меньше мест, где он сломается».

Практика: как сделать бэкап с Borg?

Рассмотрим простой пример создания бэкапа:

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

   sudo wget https://github.com/borgbackup/borg/releases/download/1.1.6/borg-linux64 -O /usr/local/bin/borg sudo chmod +x /usr/local/bin/borg

   
   Примечание: Если для теста вы используете локальную машину и как источник и как приёмник, то вся разница будет только в URI, который мы передадим, но мы же помним, что бэкап нужно хранить отдельно, а не на той же машине.
2. На сервере бэкапов создаём пользователя borg:

   sudo useradd -m borg

   
   Просто: без групп и со стандартным shell’ом, но обязательно с домашним каталогом.
3. На клиенте генерируется SSH-ключ:

   ssh-keygen

4. На сервере пользователю borg добавляем сгенерированный ключ:

   mkdir ~borg/.ssh echo 'command="/usr/local/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNdaDfqUUf/XmSVWfF7PfjGlbKW00MJ63zal/E/mxm+vJIJRBw7GZofe1PeTpKcEUTiBBEsW9XUmTctnWE6p21gU/JNU0jITLx+vg4IlVP62cac71tkx1VJFMYQN6EulT0alYxagNwEs7s5cBlykeKk/QmteOOclzx684t9d6BhMvFE9w9r+c76aVBIdbEyrkloiYd+vzt79nRkFE4CoxkpvptMgrAgbx563fRmNSPH8H5dEad44/Xb5uARiYhdlIl45QuNSpAdcOadp46ftDeQCGLc4CgjMxessam+9ujYcUCjhFDNOoEa4YxVhXF9Tcv8Ttxolece6y+IQM7fbDR' > ~borg/.ssh/authorized_keys chown -R borg:borg ~borg/.ssh

5. Инициализируем borg repo на сервере с клиента:

   ssh [email protected] hostname # просто для проверки соединения borg init -e none [email protected]:MyBorgRepo

   
   Ключ -e служит для выбора метода шифрования репозитория (да, вы можете дополнительно зашифровать каждый репозиторий своим паролем!). В данном случае, т.к. это пример, шифрованием мы не пользуемся. MyBorgRepo — это имя каталога, в котором будет borg repo (создавать его заранее не нужно — Borg всё сделает сам).
6. Запускаем первый бэкап с помощью Borg:

   borg create --stats --list [email protected]:MyBorgRepo::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" /etc /root

   
   Про ключи:
   
   • --stats и --list дают нам статистику по бэкапу и попавшим в него файлам;
   • [email protected]:MyBorgRepo — тут всё понятно, это наш сервер и каталог. А что дальше за магия?..
   • ::"MyFirstBackup-{now:%Y-%m-%d_%H:%M:%S}" — это имя архива внутри репозитория. Оно произвольно, но мы придерживаемся формата Имя_бэкапа-timestamp (timestamp в формате Python).

Что дальше? Конечно, посмотреть, что же попало в наш бэкап! Список архивов внутри репозитория:

borg@b3e51b9ed2c2:~$ borg list MyBorgRepo/ Warning: Attempting to access a previously unknown unencrypted repository! Do you want to continue? [yN] y MyFirstBackup-2018-08-04_16:55:53 Sat, 2018-08-04 16:55:54 [89f7b5bccfb1ed2d72c8b84b1baf477a8220955c72e7fcf0ecc6cd5a9943d78d]

Видим бэкап с timestamp’ом и как Borg спрашивает нас, действительно ли мы хотим обратиться к нешифрованному репозиторию, в котором ещё ни разу не были.

Смотрим список файлов:

borg list MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53

Достаём файл из бэкапа (можно и весь каталог):

borg@b3e51b9ed2c2:~$ borg extract MyBorgRepo::MyFirstBackup-2018-08-04_16:55:53 etc/hostname borg@b3e51b9ed2c2:~$ ll etc/hostname -rw-r--r-- 1 borg borg 13 Aug 4 16:27 etc/hostname

Поздравляю, ваш первый бэкап с Borg готов!

Практика: автоматизируй это [с GitLab]!

Завернув всё это в скрипты, мы настроили бэкапы вручную подобным образом примерно на 40 хостах. Поняв, что Borg действительно работает, начали переводить на него больше и более крупные проекты…

И тут мы столкнулись с тем, что есть в Bareos, но нет у Borg! А именно: WebUI или какого-то централизованного места для настройки бэкапов. И мы очень надеемся, что это временное явление, но пока нам надо было что-то решить. Погуглив готовые инструменты и собравшись в видеоконференции, мы взялись за дело. Была замечательная идея интеграции Borg с нашими внутренними сервисами, как мы делали раньше с Bacula (сама Bacula забирала список job’ов из нашего централизованного API, к которому мы имели свой интерфейс, интегрированный с другими настройками проектов). Подумали, как можно сделать, обрисовали план, как и куда это можно встроить, но… Нормальные бэкапы нужны сейчас, а на грандиозные планы времени взять неоткуда. Что делать?

Вопросы и требования стояли примерно следующим образом:

• Что использовать как централизованное управление бэкапами?
• Что умеет любой Linux-администратор?
• Что сможет понять и настроить даже менеджер, показывающий график бэкапов клиентам?
• Что каждый день выполняет по расписанию задания на вашей системе?
• Что не будет трудным в настройке и не будет ломаться?..

Ответ был очевиден: это старый добрый crond, который героически выполняет свой долг каждый день. Простой. Не зависает. Сможет поправить даже менеджер, который с Unix на «вы».

Итак, crontab, но где же всё это держать? Неужели каждый раз ходить на машину проекта и править файл руками? Конечно, нет. Мы можем положить наше расписание в Git-репозиторий и настроить GitLab Runner, который по коммиту будет обновлять его на хосте.

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

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

Итак, вот что понадобится для простой автоматизации:

1. GitLab и репозиторий, в котором для начала будет два файла:

• schedule — расписание бэкапов,
• borg_backup_files.sh — простой скрипт бэкапа файлов (как в примере выше).

Пример schedule:

# WARNING! CRONTAB MANAGED FROM GITLAB CI RUNNER IN ${CI_PROJECT_URL} # CI_COMMIT_SHA: ${CI_COMMIT_SHA} # Branch/tag: ${CI_COMMIT_REF_NAME} # Timestamp: ${TIMESTAMP} PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin # MyRemoteHost 0 0 * * * ${CI_PROJECT_DIR}/borg_backup_files.sh 'SYSTEM /etc,/opt'

Переменные CI используются для того, чтобы проверить успешность обновления crontab’а, а CI_PROJECT_DIR — каталог, в котором окажется репозиторий после клонирования runner’ом. Последняя строка указывает на то, что бэкап выполняется каждый день в полночь.

Пример borg_backup_files.sh:

#!/bin/bash BORG_SERVER="[email protected]" NAMEOFBACKUP=${1} DIRS=${2} REPOSITORY="${BORG_SERVER}:$(hostname)-${NAMEOFBACKUP}" borg create --list -v --stats \ $REPOSITORY::"files-{now:%Y-%m-%d_%H:%M:%S}" \ $(echo $DIRS | tr ',' ' ') || \ echo "borg create failed"

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

2. GitLab Runner, запущенный на машине, которую необходимо бэкапить, и заблокированный только на выполнение job’ов этого репозитория.

3. Сам CI-сценарий, реализуемый файлом .gitlab-ci.yml:

stages: - deploy Deploy: stage: deploy script: - export TIMESTAMP=$(date '+%Y.%m.%d %H:%M:%S') - cat schedule | envsubst | crontab - tags: - borg-backup

4. SSH-ключ у пользователя gitlab-runner c доступом к серверу бэкапов (в примере это 10.100.1.1). По умолчанию он должен лежать в .ssh/id_rsa домашнего каталога пользователя (gitlab-runner).

5. Пользователь borg на том же 10.100.1.1 с доступом только к команде borg serve:

$ cat .ssh/authorized_keys command="/usr/bin/borg serve" ssh-rsa AAAAB3NzaC1yc2EAA...

Теперь при коммите в репозиторий Runner заполнит содержимое crontab’а. А при наступлении времени срабатывания cron’а выполнится бэкап каталогов /etc и /opt, который окажется на сервере бэкапов в каталоге MyHostname-SYSTEM сервера 10.100.1.1.

Вместо заключения: что можно ещё?

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

• Добавить универсальные скрипты для разных бэкапов, которые по окончанию выполнения запускают borg_backup_files.sh, направленный на каталог с результатом своей работы. Например, так можно бэкапить PostgreSQL (pg_basebackup), MySQL (innobackupex), GitLab (встроенный rake job, создающий архив).
• Центральный хост со schedule для бэкапа. Не настраивать же на каждом хосте GitLab Runner? Пусть он будет один на сервере бэкапов, а crontab при запуске передаёт скрипт бэкапа на машину и запускает его там. Для этого, конечно, понадобится пользователь borg на машине клиенте и ssh-agent, чтобы не раскладывать ключ к серверу бэкапов на каждой машине.
• Мониторинг. Куда же без него! Алерты о некорректно завершённом бэкапе обязательно должны быть.
• Очистка borg repository от старых архивов. Несмотря на хорошую дедупликацию, старые бэкапы всё равно приходится чистить. Для этого можно сделать вызов borg prune по окончанию работы скрипта бэкапа.
• Веб-интерфейс к расписанию. Пригодится, если правка crontab руками или в web-интерфейсе для вас выглядит не солидно/неудобно.
• Pie charts. Немного графиков для наглядного представления процента успешно выполненных бэкапов, времени их выполнения, ширины «съеденного» канала. Не зря я уже писал, что не хватает WebUI, как в Bareos…
• Простые действия, которые хотелось бы получать по кнопке: запуск бэкапа по требованию, восстановление на машину и т.п.

И в самом конце хотелось бы добавить пример эффективности дедупликации на реальном рабочем бэкапе WAL-файлов PostgreSQL в production-среде:

borg@backup ~ $ borg info PROJECT-PG-WAL Repository ID: 177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Location: /mnt/borg/PROJECT-PG-WAL Encrypted: No Cache: /mnt/borg/.cache/borg/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 Security dir: /mnt/borg/.config/borg/security/177eeb28056a60487bdfce96cfb33af1c186cb2a337226bc3d5380a78a6aeeb6 ------------------------------------------------------------------------------ Original size Compressed size Deduplicated size All archives: 6.68 TB 6.70 TB 19.74 GB Unique chunks Total chunks Chunk index: 11708 3230099

Это 65 дней бэкапа WAL-файлов, которые делались каждый час. При использовании Bacula/Bareos, т.е. без дедупликации, мы получили бы 6,7 Тб данных. Только подумайте: можем позволить себе хранить почти 7 терабайт данных, прошедших через PostgreSQL, всего в 20 Гб фактически занимаемого места.

P.S.

Читайте также в нашем блоге:

Бэкап - это... Что такое Бэкап?

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

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

Цель

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Борьба:

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

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

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

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

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

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

См. также

Ссылки

Wikimedia Foundation. 2010.

Обзор и тестирование rsync-based средств резервного копирования / Southbridge corporate blog / Habr

Данной статьей продолжается цикл о резервном копировании

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

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

Из тех, что больше всего подходят под наши условия, я буду рассматривать 3: rdiff-backup, rsnapshot и burp.

Тестовые наборы файлов

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

Первый набор: 10 Гб медиафайлов, и примерно 50 мб — исходный код сайта на php, размеры файлов от нескольких килобайт для исходного кода, до десятков мегабайт для медиафайлов. Цель — имитация сайта с статикой.

Второй набор: получается из первого при переименовании подкаталога с медиафайлами размером 5 гб. Цель — изучение поведения системы резервного копирования на переименование каталога.

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

Получение результатов

Любое резервное копирование выполняется минимум 3 раза и сопровождается сбросом кэшей файловой системы командами sync и echo 3 > /proc/sys/vm/drop_caches как на стороне тестового сервера, так и сервера хранения резервных копий.

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

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

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

Сейчас у них следующие характеристикиПроцессор

sysbench --threads=2 --time=30 --cpu-max-prime=20000 cpu run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 2 Initializing random number generator from current time Prime numbers limit: 20000 Initializing worker threads... Threads started! CPU speed: events per second: 1081.62 General statistics: total time: 30.0013s total number of events: 32453 Latency (ms): min: 1.48 avg: 1.85 max: 9.84 95th percentile: 2.07 sum: 59973.40 Threads fairness: events (avg/stddev): 16226.5000/57.50 execution time (avg/stddev): 29.9867/0.00 

Оперативная память, чтение...

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=read memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: read scope: global Initializing worker threads... Threads started! Total operations: 104857600 (5837637.63 per second) 102400.00 MiB transferred (5700.82 MiB/sec) General statistics: total time: 17.9540s total number of events: 104857600 Latency (ms): min: 0.00 avg: 0.00 max: 66.08 95th percentile: 0.00 sum: 18544.64 Threads fairness: events (avg/stddev): 26214400.0000/0.00 execution time (avg/stddev): 4.6362/0.12 

… и запись

sysbench --threads=4 --time=30 --memory-block-size=1K --memory-scope=global --memory-total-size=100G --memory-oper=write memory run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time Running memory speed test with the following options: block size: 1KiB total size: 102400MiB operation: write scope: global Initializing worker threads... Threads started! Total operations: 91414596 (3046752.56 per second) 89272.07 MiB transferred (2975.34 MiB/sec) General statistics: total time: 30.0019s total number of events: 91414596 Latency (ms): min: 0.00 avg: 0.00 max: 1022.90 95th percentile: 0.00 sum: 66430.91 Threads fairness: events (avg/stddev): 22853649.0000/945488.53 execution time (avg/stddev): 16.6077/1.76 

Диск на сервере-источнике данных

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time 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... Threads started! File operations: reads/s: 4587.95 writes/s: 3058.66 fsyncs/s: 9795.73 Throughput: read, MiB/s: 17.92 written, MiB/s: 11.95 General statistics: total time: 60.0241s total number of events: 1046492 Latency (ms): min: 0.00 avg: 0.23 max: 14.45 95th percentile: 0.94 sum: 238629.34 Threads fairness: events (avg/stddev): 261623.0000/1849.14 execution time (avg/stddev): 59.6573/0.00 

Диск на сервере хранения резервных копий

sysbench --threads=4 --file-test-mode=rndrw --time=60 --file-block-size=4K --file-total-size=1G fileio run sysbench 1.0.17 (using system LuaJIT 2.0.4) Running the test with following options: Number of threads: 4 Initializing random number generator from current time 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... Threads started! File operations: reads/s: 11.37 writes/s: 7.58 fsyncs/s: 29.99 Throughput: read, MiB/s: 0.04 written, MiB/s: 0.03 General statistics: total time: 73.8868s total number of events: 3104 Latency (ms): min: 0.00 avg: 78.57 max: 3840.90 95th percentile: 297.92 sum: 243886.02 Threads fairness: events (avg/stddev): 776.0000/133.26 execution time (avg/stddev): 60.9715/1.59 

Скорость сети между серверами

iperf3 -c backup Connecting to host backup, port 5201 [ 4] local x.x.x.x port 59402 connected to y.y.y.y port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 419 MBytes 3.52 Gbits/sec 810 182 KBytes [ 4] 1.00-2.00 sec 393 MBytes 3.30 Gbits/sec 810 228 KBytes [ 4] 2.00-3.00 sec 378 MBytes 3.17 Gbits/sec 810 197 KBytes [ 4] 3.00-4.00 sec 380 MBytes 3.19 Gbits/sec 855 198 KBytes [ 4] 4.00-5.00 sec 375 MBytes 3.15 Gbits/sec 810 182 KBytes [ 4] 5.00-6.00 sec 379 MBytes 3.17 Gbits/sec 765 228 KBytes [ 4] 6.00-7.00 sec 376 MBytes 3.15 Gbits/sec 810 180 KBytes [ 4] 7.00-8.00 sec 379 MBytes 3.18 Gbits/sec 765 253 KBytes [ 4] 8.00-9.00 sec 380 MBytes 3.19 Gbits/sec 810 239 KBytes [ 4] 9.00-10.00 sec 411 MBytes 3.44 Gbits/sec 855 184 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec 8100 sender [ 4] 0.00-10.00 sec 3.78 GBytes 3.25 Gbits/sec receiver 

Методика тестирования

1. На тестовом сервере подготавливается файловая система с первым тестовым набором, на сервере хранения резервных копий при необходимости инициализируется репозиторий.
   Запускается процесс резервного копирования и замеряется его время.
2. На тестовом сервере производится миграция файлов до второго тестового набора. Запускается процесс резервного копирования и замеряется его время.
3. На тестовом сервере производится миграция до третьего тестового набора. Запускается процесс резервного копирования и замеряется его время.
4. Полученный третий тестовый набор принимается новым первым; пункты 1-3 повторяются еще 2 раза.
5. Данные заносятся в сводную таблицу, добавляются графики с netdata.
6. Составляется отчет по отдельному методу резервного копирования.

Ожидаемые результаты

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

1. Файлы в репозитории будут храниться «как есть».
2. Размер репозитория будет расти только включая разницу между резервными копиями.
3. Будет сравнительно большая нагрузка на сеть при передаче данных, а также небольшая нагрузка на процессор.

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

Узкое место было на сервере хранения резервных данных в виде диска на основе HDD, что достаточно четко видно на графиках в виде пилы.

Данные были скопированы за 4 минуты и 15 секунд.

Тестирование rdiff-backup

Первый кандидат — rdiff-backup, скрипт на python, который выполняет резервное копирование одного каталога в другой. При этом текущая резервная копия хранится «как есть», а резервные копии, сделанные ранее, складываются в специальный подкаталог инкрементально, и таким образом, экономится место.

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

Давайте посмотрим,

на что он способен в наших условиях.

Время работы каждого тестового запуска:

Rdiff-backup весьма болезненно реагирует на любое большое изменение данных, также не до конца утилизирует сеть.

Тестирование rsnapshot

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

Также инвертирована логика процесса резервного копирования: сервер активно «ходит» сам по своим клиентам и забирает данные.

Результаты тестирования

получились следующие
Отработал весьма и весьма быстро, гораздо быстрее rdiff-backup и очень близко к чистому rsync.

Тестирование burp

Еще один вариант — реализация на C поверх librsync — burp, имеет клиент-серверную архитектуру включая авторизацию клиентов, а также наличие web-интерфейса (не входит в базовую поставку). Еще одна интересная особенность — резервное копирование без права восстановления у клиентов.

Давайте посмотрим на

производительность.

Отработал в 2 раза медленнее, чем rsnapshot, однако тоже достаточно быстро, и уж точно быстрее rdiff-backup. Графики немного пилообразны — производительность опять же упирается в дисковую подсистему сервера хранения резервных копий, хотя это и не так выражено, как у rsnapshot.

Результаты

Размер репозиториев у всех кандидатов был примерно одинаковым, т. е. сначала рост до 10 гб, потом рост до 15 гб, потом рост до 18 гб и т.д., что связано с особенностью работы rsync. Также стоит отметить однопоточность всех кандидатов (загрузка по процессору около 50% при двухядерной машине). Все 3 кандидата предоставляли возможность восстановления последней резервной копии «как есть», то есть можно было восстанавливать файлы без применения каких-либо сторонних программ включая те, которые применялись для создания репозиториев. Это также «родовое наследие» rsync.

Выводы

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

Анонс

Данная заметка продолжает цикл о резервном копировании

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

Автор публикации: Finnix

---

Смотрите также

• 
  Мезотерапия волос что это такое фото
• 
  Шейдер что это такое
• 
  Усы дракона что это такое
• 
  Острый назофарингит что это такое
• 
  Силикатное стекло что это такое
• 
  Паркинг что это такое
• 
  Фолликулярный узел щитовидной железы что это такое
• 
  Синдром свайера что это такое
• 
  Ишемический инфаркт головного мозга что это такое
• 
  Дезагрегационная тромбоцитопатия что это такое
• 
  Сметанный продукт что это такое