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

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

Те файлы которые вам не нужны сейчас, наверняка могут вам понадобиться завтра или через 5 лет. А где эти файлы? — Да на старом компьютере/флэшке/отформатированном съемном носителе…

А должно всё это храниться в резервных копиях. В зашифрованном виде (по обстоятельствам), на резервируемом носителе.

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

1#. Резервное копирование данных на каждом отдельно стоящем компьютере:

На рабочих станциях пользователей должно быть настроено теневое резервное копирование штатными средствами windows. (В windows 7 делается через свойства значка компьютер > Дополнительные параметры системы > Защита системы ). Можно включить как бэкап реестра при изменениях (контрольные точки), так и сохранение состояний файлов на локальных дисках. Придется пожертвовать свободным местом на HDD, но нервы дороже.

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

Если штатное резервное копирование не может быть использовано по какой либо из причин, можно воспользоваться сторонним софтом таким как acronis backup and recovery (платный) или (бесплатный). Программ на эту тему — масса .

Однако, резервное копирование данных в пределах одного физического диска не избавит вас от опасности его выхода из строя. Сложно оценить ценность бэкапа, когда он вместе с исходными данными находится в битых секторах на HDD:)

Скажем так — резервное копирование системы штатными средствами: «must have». Но важные вещи постарайтесь дублировать в сеть. Для это можно:

а) Воспользоваться хостингом VDS (самый дешевый тариф с 5ГБ пространства 100 р. в месяц)

б) Использовать бесплатное место на облачных сервисах (google drive, icloud, yandex disk и т.д.). Например гугл диск поддерживает восстановление предыдущих версий файлов. И даже если непреднамеренно измененный файл уже синхронизирован — его всегда можно восстановить. Можете прочесть полезные советы по google drive .

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

2#. Резервное копирование данных на фирме с несколькими (и более 10) рабочими станциями.

Идеальным вариантом для резервного копирования на предприятии будет наличие централизованного сервера внутри компании (FTP сервер с RAID 1) или за её пределами (VDS сервер со службой FTP).

Хранить, скажем, базу данных 1С или договора на Google-диске не совсем безопасно, т.к. потеряв доступ к почте или если доступ оказался в руках злоумышленников фирма определенно пострадает. Хотя у автора есть знакомые индивидуальные предприниматели которые только так и работают. У последних на гугл-диск всё помещается в зашифрованном виде;)

а) В случае с сервером внутри компании необходимы разовые затраты на сам файловый сервер (50-100 тыс. руб) в зависимости от уровня надежности. Затем затраты могут возникать при поломке железа (что бывает не часто). Также учтите затраты на электроэнергию.

б) В случае с внешним хранилищем на VDS, вы платите 1 раз за настройку администратором по ИТ-аутсорсингу (в районе 5 тыс. руб, в зависимости от количества компьютеров для бэкапа) и ежемесячно 500-900 рублей (в зависимости от объемов информации) за хостинг VDS. Учтите, что в этом случае нужен интернет пошустрее. Хотя бы 5 Мбит/с исходящей скорости.

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

Ниже схематично представлены варианты резервного копирования для совсем небольшого предприятия 5-30 компьютеров.

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

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

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

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

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

Программное обеспечение как вариант можно использовать Areca (кроссплатформенное java-приложение) + планировщик задач Windows. В Areca создается скрипт с параметрами резервного копирования (куда копировать, шифрование, вид и имена копий) который добавляется в планировщик задач windows или cron Unix. Можете ознакомиться со статьей по .

Как кажется автору, вариант б) более предпочтителен, ведь у компании почти пропадает головная боль относительно сохранности резервных данных. Но здесь тоже есть пара минусов: — если вы используете VDS для бэкапа, то этот сервер уже ни с чем не совместить. Можно конечно туда поместить и ваши приложения (1с), но тогда помимо дискового пространства вам придется платить еще и за дополнительное процессорное время и память (а это уже другие суммы).

Еще один очевидный минус — это . И при отсутствии вменяемого провайдера поблизости вам остается только вариант а).

Итак второй вариант с VDS(б):

Данные идут в том же направлении как и на первой схеме (на рисунке не показаны), однако теперь все отправляется через интернет на удаленный VDS-сервер. Areca отлично шифрует данные еще на стороне пользователя и они в таком виде помещаются на VDS по протоколу FTP. В качестве FTP-сервера на VDS Можно довольно быстро поднять vsftpd , пример его настройки есть .

Стоит учесть один нюанс: «Копирование файлов по протоколу ftp с SSL или TLS — значительно замедляет процесс, а при больших объемах данных может и зависнуть вовсе».

Нужно лишь продумать политику резервного копирования, а именно: «Собирать все важные данные сначала внутри сети на какм-либо сетевом хранилище (общая папка например) и потом под одной учетной записью FTP сбрасывать их на VDS в назначенное время. Или сбрасывать данные со всех компьютеров в разное время под разными учетными записями». Первый вариант будет лучше если компьютеров больше 5. Если же сеть небольшая то и отдельное сетевое хранилище выделять не нужно.

Как делать бэкапы — решать вам, здесь были представлены наиболее бюджетные варианты резервного копирования.

Пользователи прочитавшие эту запись обычно читают:

Вконтакте

Простой сервер резервного копирования

• Чулан *

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

Резервное копирование бывает ручное и автоматическое. Также не стоит путать резервное копирование с архивированием. Задача резервного копирования - хранить несколько актуальных версий данных на случай “все пропало, нужно срочно восстановить”. Архивирование же предназначено для доступа к данным за прошлый год, или прошлую пятилетку. Мы эти две услуги объединяем. Обычно ежедневные резервные копии хранятся в течении месяца, а ежемесячные - пожизненно. При необходимости срок хранения можно изменить.

Рассмотрим резервное копирование в разрезе сервисов.

1. Резервное копирование баз данных 1С
Тут есть два варианта первый - простой и правильный. База находится на терминальном сервере 1С, на этом сервере по расписанию запускается скрипт, который проводит архивацию базы с паролем, который известен только клиенту и пересылает эту базу по протоколу FTP на наш бекап сервер, который архив принимает и надежно хранит.
Если же база находится на компьютере бухгалтера и все коллеги к ней подключаются по общей сетевой папке, то расписание резервного копирования можно составить таким образом, чтобы во время копирования все сотрудники уже отдыхали, но компьютер уже был включен, например на 10 вечера с последующим выключением компьютера. Либо же запускать backup скрипт вручную, когда бухгалтер идет домой. Но в таком случае мы советуем перейти на терминальный сервер, что мы тоже можем помочь сделать.
Ручное копирование можно запустить в любой момент, это делается одним кликом.

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

2. Резервное копирование веб сайтов
Хотя хостинг достаточно надежная штука - иметь бекапы под рукой на случай откатывания версии назад, или срочного восстановления сайта на другой площадке хочется всегда. Скажем даже так: бекапы делают и сами хостеры, но обычно эти бекапы хранятся не долго, сделаны в своем формате, недоступны, когда хостер «лежит». В этих случаях держать актуальную версию сайта в удобном для вас формате на отдельной технической площадке - мечта параноика.
Сайт состоит из двух частей: база данных и файлы. Бекапим обе. Технически автоматическое резервное копирование сайта происходит так: каждую ночь в заданное время бекап сервер обращается к веб сервер с просьбой отдать бекап, тот в свою очередь архивирует дамп БД и файлы, и пересылает все на бекап сервер.
Возможно создать резервную копию сайта вручную. В панели управления нашей CMS есть волшебная кнопка “бекап”, по нажатию которой создается архив и отсылается на бекап сервер. В зависимости от размера сайта (через 5 секунд, или 20) резервная копия уже находится в надежном месте, а вам на почту приходит отчет о ее успешном завершении, либо о ошибке (если такова присутствует).

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

4. Резервное копирование пользовательских данных.
В идеальном варианте все пользовательские данные находятся в системе хранения данных (СХД) и надежно защищены. Но это далеко не всегда так. Особенно ситуация усложняется, если у предприятия несколько маленьких офисов или есть удаленные сотрудники. В таком случае можно настроить резервное копирование самых важных данных непосредственно с рабочих машин, или локальных файловых серверов. Если количество данных большое и измеряется гигабайтами, можно организовать локальный сервер резервного копирования. Или в случае, если используется домен Windows - файловый сервер для хранения пользовательских профилей.
Для современного взаимодействия сейчас используются облачные хранилища информации. Данные из Google Drive тоже имеет смысл резервировать, т.к. владелец может удалить данные, и у тех кто их совместно использует ничего не останется. Мы периодически резервируем гугл документы с помощью программы GDocBackup и соответствующего скрипта который архивирует с паролем и отправляет на сервер резервного копирования.

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

Что представляет собой наш бекап сервер?
Физически сервер установить очень просто, гораздо сложнее и интереснее организовать систему резервного копирования. Жесткие диски поставили в RAID-1 для обеспечения зеркалирования данных, настроили отчет на email при выходе из строя одного из дисков. Процессор - Intel Atom, просто и дешево, ведь задача сервера - только хранить данные. А точнее ночами получать несколько десятков гигабайт, а по запросу (обычно днем) отдавать несколько гигабайт. Сервер размещен в серверной комнате, запитан через источник бесперебойного питания и подключен к интернет через оптический кабель.
Используется операционная система Linux Debian, что также обеспечивает стабильность работы.

Не взирая на важность всего комплекса мероприятий по резервированию, основным элементом все же является программно-прикладное обеспечение. Основными, наиболее востребованными производителями программного обеспечения являются VmWare, Acronis. Veeam.

Начнем рассмотрение преимуществ с программных продуктов производимых компанией Acronis. Одним из них является Acronis Backup & Recovery Virtual Edition

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

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

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

К примеру, корпорация VmWare производит такой программный продукт как VmWare Data Recovery для виртуальных машин на ESX. Ввиду того, что данный производитель лидирует в сфере виртуализации, он должен был по умолчанию подвинуть конкурентов по резервному копированию в своей отрасли. Тем не менее, этого не произошло. Причиной этому является тот факт, что данный продукт является относительно простым. Фактически он ориентирован на отрасли, для которых сохранность данных не является особо критичной характеристикой и достаточен простейший механизм резервирования. VMware Data Recovery может создавать резервную копию виртуальной машины только на уровне образа (файлов vmdk), а восстанавливать может как образ целиком, так и отдельные файлы в гостевую ОС.

В промышленной же среде более-менее крупных компаний, потребуются такие функции как:

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

Все эти функции есть в Veeam Backup. Которая, фактически, и является наилучшим решением в области резервного копирования в сфере виртуализации.

Данный продукт многофункционален, может исполнять большинство функций, правда изрядное количество дополнительных параметров являются опциями, что повысит его стоимость при приобретении полного пакета. Но, тем не менее, сама программа Veeam BackUp & Replication является законченным продуктом, использующимся во многих компаниях, как малых, так и крупных. Эта программа включает в себя 2 модуля: создание резервных копий и их репликацию.

Кратко архитектура построения резервного копирования Veeam Backup выглядит так:

Veeam Backup сервер запускает задание и определяет оптимальный Veeam Backup Proxy для копирования данных. Veeam Backup Proxy вытаскивает данные виртуальных машин vSphere, дедуплицирует данные, архивирует и потоком передает на Veeam Backup Repository. Veeam Backup Repository записывает данные на диск в резервные копии, а также следит за политикой хранения копий: например, при необходимости собирает полные синтетические копии.

Рисунок 38 Схематическое изображение принципа работы сервиса

Veeam Backup Proxy при этом может быть физическим сервером или виртуальной машиной с ОС MS Windows, а способы извлечения данных могут при этом быть: по сети SAN, через технологию VMware Hot Add или по сети LAN.

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

Данный продукт полностью поддерживает ESX и ESXi, включая такие функции как «тонкие диски», Сhanged Block Tracking, vStorage APIs for Data Protection, vApp, HotAdd.

Помимо стандартных функций, предусмотренных в самой платформе виртуализации, существуют и специфические, такие как Veeam Power. Данная технология дает возможность запуска виртуальной машины прямо из файла резервной копии, даже если файл был подвергнут сжатию и дедупликации, без предварительного восстановления. Она позволяет сократить время простоя в случае аварии, запускать резервные копии для проверки того, что копия была сделана правильно (SureBackup). В пакет могут войти Veeam Backup Enterprise Manager – инструмент для централизованного управления резервным копированием, лицензиями на Veeam BR, обновлениями.

Рисунок 39 Схематическое изображение принципа работы сервиса Veeam Backup Enterprise Manager

Guest OS Files and VM Files Recovery – возможность восстановления отдельных фалов и папок из резервных копий виртуальных машин. Что также в некоторых случаях способно значительно сократить время для восстановления работоспособности системы. Для восстановления одного или нескольких поврежденных файлов нет необходимости восстанавливать весь массив данных.

Incremental and Reversed Incremental backup – у продукта Veeam есть два метода резервного копирования: инкрементный – более быстрый, который рекомендуется для резервирования диск-диск-ленточный накопитель, и обратно инкрементный или синтетический – рекомендуется для резервирования диск-диск и позволяет сохранить полную резервную копию последнего резервирования.

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

Рисунок 40 Схематическое изображение добавочного типа резервирования.

Рисунок 41 Схематическое изображение инкрементного типа резервирования.

Data De-Duplication and Compression – обе технологии позволяют уменьшить требующееся место для резервного копирования виртуальных машин. Дедупликация позволяет во время резервного копирования нескольких виртуальных машин не сохранять повторяющиеся блоки, к примеру, когда резервируется несколько операционных систем одного поколения.

Еще одна функция, которая позволяет уменьшить размер резервных копий это сжатие (compression). При ее использовании может увеличиваться время создания резервной копии и нагрузка на аппаратные мощности. И, наконец, функция Reporting позволяет формировать отчеты о работе Veeam BR.

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

Нет похожих статей.

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

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

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

1. Установка программы

И так перейдем к установке программы. Скачиваем дистрибутив программы с официального сайта и запускаем скаченный файл. На первой странице инсталлятора выбираем тот язык который вам нужен и нажимаем «Далее» .

На следующей страничке нам предложат ознакомиться с лицензионным соглашением и принять условия этого соглашения. Жмем «Далее» .

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

• «Инициатор теневого копирования» служит для того, чтобы копировать файлы, даже тогда, когда они открыты или используются приложениями. Я рекомендую его установить, но если допустим бэкап вам нужен для одного раза, то в принципе инициатор теневого копирования можно не устанавливать. Для работы инициатора теневого копирования требуется наличие установленного Microsoft .NET Framework 3.5 . Как установить компоненту.NET Framework в , читайте .
• «Сценарий установки» нужен для того, что бы запомнить все параметры текущей установки, и при следующей установке, сделать все то же самое, без вашего участия.

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

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

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

Все, на этом установка закончена.

2.Настройка программы

Приступим к основной задаче настройки задания бэкапа. Запускаем программу, в меню выбираем «Задание» , затем «Новое задание» .

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

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

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

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

Переходим на вкладку «Цикличность». З десь можно настроить приоритет вашего задания и для экономия места можно настроить число хранения полных копий.

Переходим на вкладку «Сжатие» и указываем какое нам нужно сжатие и деление на части ваших файлов.

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

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

Помогла ли Вам Данная статья?

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

Ранее я уже неоднократно рассматривал вопрос резервного копирования данных или целых серверов linux. Конкретно в этих статьях:

Забэкапить сразу весь сервер можно, например, с помощью Duplicity. Но вот восстановить его на другом железе будет не так просто. Помимо данных нужно будет, как минимум, позаботиться о разметке диска, установке загрузчика. На это необходимо затратить некоторые усилия и немного разбираться в теме initramfs и grub. Сам я не очень разбираюсь в нюансах работы этих инструментов и очень не люблю с ними возиться.

Некоторое время назад появился отличный бесплатный продукт для бэкапа всего сервера целиком. Речь идет о Veeam Agent for Linux FREE . С его помощью можно сделать полный backup сервера, положить его куда-нибудь по smb или nfs , потом загрузиться с live cd и восстановить из бэкапа на другом железе.

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

1. Бэкап можно сделать либо всего сервера сразу, либо отдельного диска, либо отдельных папок и файлов. При выборе бэкапа всего диска или сервера, нельзя задать исключения для отдельных папок или файлов. Это очень неудобно, но увы и ах, таков функционал. Исключения можно сделать только если вы делаете бэкап на уровне папок.
2. Бэкап можно положить локально на соседний раздел, если делаете резервную копию раздела, локально в папку — если делаете бэкап файлов и папок. Если бэкапите всю систему целиком, то удаленно по smb и nfs. К сожалению, по ftp или sftp программа не работает.

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

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

Думаю вы уже поняли, в чем проблема сделать полный backup сервера с помощью Veeam Agent for Linux на Яндекс.Диск по webdav. Вы не сможете добавить в исключения папку с кэшом от webdav. В итоге, во время бэкапа с помощью veeam будет расти папка с кэшом webdav, которая, в свою очередь, будет бэкапиться. В итоге, свободное место на диске закончится, бэкап прервется.

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

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

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

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

# cd /root # wget https://download2.veeam.com/veeam-release-el7-1.0-1.x86_64.rpm # rpm -Uhv veeam-release-el7-1.0-1.x86_64.rpm

Обновляем репозитории и устанавливаем veeam.

# yum update # yum install veeam

Все, Veeam Agent for Linux установлен и готов к работе.

Настройка полного бэкапа сервера

Сделать бэкап с помощью Veeam Agent for Linux очень просто. Вариантов настроек не так много, можете сами все проверить и посмотреть. Я для примера рассмотрю вариант с созданием полного бэкапа всей системы и перенос ее на другое железо. Создаем задачу для резервного копирования сервера на наше хранилище по smb.

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

Нажимаем C (configure) для настройки задания на backup. Задаем любое имя задания, затем указываем, что будем делать полный бэкап сервера.

В качестве приемника для архива системы, указываем Shared Folder .

В пункте Restore Points указывается глубина архива. Это число копий, которые будут храниться на сервере. Если делать бэкап каждый день и указать число 14, то будут храниться резервные копии системы за последние 14 дней. Если делать будете через день, то за 28 дней и т.д.

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

Если получите ошибку:

Current system does not support cifs. Please install cifs client package.

Установите пакет cifs . В CentOS вот так:

# yum install cifs-utils

И так в Debian/Ubuntu:

# apt install cifs-utils

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

Запустилась архивация. Можно следить за ее прогрессом.

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

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

Перенос или восстановление linux сервера

Представим теперь ситуацию, что наш веб, или какой-нибудь другой сервер умер, и нам надо восстановить систему в другом месте. Выполним полное восстановление всего сервера с помощью созданной ранее резервной копии. Для этого нам понадобится Veeam Linux Recovery Media , который мы скачали ранее.

Для восстановления системы нужно соблюсти два обязательных условия:

1. Готовим новый сервер с диском, который должен быть не меньше диска исходного сервера. Это обязательное условие, иначе восстановление системы даже не начнется. Veeam скажет, что размер диска недостаточный и не предложит больше никаких вариантов восстановления.
2. Оперативной памяти для системы должно быть не меньше 1024 Мб. Если меньше, то загрузка с диска не будет выполнена. Система скажет, что она не может развернуть корневой раздел.

Загружаемся с диска. В разделе Configure network убеждаемся, что сеть настроена, получен ip адрес, который имеет доступ к интернету. Далее выбираем Restore volumes -> Add shared folder . Заполняем параметры доступа к хранилищу архивов.

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

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

У меня слева чистый диск, справа тоже один диск, на который установлен загрузчик и есть один раздел с корнем системы. Выбираем справа наш диск (не раздел с корнем!!!) и жмем Restore whole disk to .

В качестве приемника выбираем пустой диск на новом сервере.

Нажимаем S (Start restore) . Визард покажет список действий, которые будут выполнены и попросит их подтвердить, нажатием на Enter.

Делаем это и наблюдаем за процессом восстановления сервера centos из бэкапа.

Дожидаемся окончания переноса сервера, выбираем перезагрузку и извлекаем загрузочный CD. Грузимся с жесткого диска.

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

Перенос виртуальной машины с KVM на Hyper-V

В моем случае я переношу сервер с KVM на Hyper-V. После загрузки системы я получаю такую картину.

Сервер начинает бесконечно висеть в подобном состоянии с такими характерными ошибками:

Warning: dracut-initqueue timeout starting timeout scripts a start job is running for dev-disk-by ......

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

В нашей ситуации с переносом виртуальной машины с KVM на Hyper-V проблема в другом. У нас поменялось имя диска. Нам нужно изменить это имя в fstab и в конфиге grub . До кучи я еще собрал заново initramfs, но не уверен на 100%, что в данном случае это нужно было делать. Я сделал на всякий случай сразу все за один заход.

Итак, загружаемся с установочного диска CentOS 7 и выбираем режим Rescue a CentOS system . Подробно об этом рассказывал в упомянутой ранее статье с переносом от xen. Выбираем первый режим запуска.

# fdisk -l

У меня это sda , а на прошлом сервере он назывался vda . Нам нужно внести эти изменения в 2 файла:

1. /etc/fstab
2. /boot/grub2/grub.cfg

Диск восстановления в самом начале мог сам смонтировать системный раздел в директорию/mnt/sysimage . Если он этого не сделает по какой-то причине, то сделайте это сами:

# mount /dev/sda1 /mnt/sysimage

Теперь нам надо сделать chroot в систему, предварительно смонтировав туда информацию о текущей системе. Выполняем команды:

# mount --bind /proc /mnt/sysimage/proc # mount --bind /dev /mnt/sysimage/dev # mount --bind /sys /mnt/sysimage/sys # mount --bind /run /mnt/sysimage/run # chroot /mnt/sysimage

Мы загрузились в окружение нашего сервера. Тут можете использовать установленный у вас на сервере текстовый редактор. С его помощью изменяете имена дисков в файлах /etc/fstab и /boot/grub2/grub.cfg . Можете просто автозаменой поменять имена.

Теперь соберем новый initramfs . Идем в директорию /boot и смотрим там последнюю версию ядра.

# cd /boot # ls -l | grep initramfs

В данном случае просто смотрим самые высокие цифры. Соберем новый initramfs в соответствии с версией ядра.

# dracut initramfs-3.10.0-514.26.2.el7.x86_64.img 3.10.0-514.26.2.el7.x86_64

В завершении установим измененный загрузчик на наш диск:

# grub2-install /dev/sda

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

Заключение

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

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

1. Неподходящие версии ядер. После переноса нужно будет переустановить или обновить ядро.
2. Разные имена дисков или меток разделов. Нужно будет их привести в соответствие с новым железом.

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

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

Онлайн курс "Администратор Linux"