Главная » Разное » Бэкап что это такое и зачем

Бэкап что это такое и зачем


Все о бекапе Android-приложений — «Хакер»

Содержание статьи

Как гласит известная айтишная мудрость, сисадмины делятся на тех, кто не делает бэкапы, и тех, кто уже делает бэкапы. Думаю, каждому хоть раз после прошивки или сбоя приходилось настраивать телефон/планшет с нуля. А ведь делать это совсем не обязательно, если есть сохраненный бэкап. В данной статье мы рассмотрим разные виды бэкапа (резервной копии) содержимого Android-устройств на все случаи жизни.

 

Введение

Получив root на смартфоне, среднестатистический пользователь начинает экспериментировать с устройством и ставить различные модификации интерфейса, темы, шрифты, новые ядра, прошивки, радио и root-приложения. Как постоянный, давний и активный пользователь форумов 4PDA и XDA Developers, могу утверждать, что очень часто такие эксперименты заканчиваются вопросами с формулировками: «Телефон не загружается, что мне делать?»

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

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

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

WARNING

Большинство описанных в статье приложений требуют root и BusyBox.

 

Бэкап приложений и их данных.

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

Titanium Backup

Мощнейшее средство бэкапа, восстановления, заморозки и удаления приложений вместе с их данными (включая системные и предустановленные производителем). Позволяет настроить автоматический бэкап по расписанию, не закрывая приложения, и переносить любое приложение на SD-карту. Можно хранить разные бэкапы одного приложения, сохранять СМС, ММС, историю звонков, закладки браузера, точки доступа Wi-Fi в форме XML-файла. Может синхронизировать все бэкапы в Dropbox, Box и Google Drive. С помощью этого приложения легко сделать любое пользовательское приложение системным, добавить шифрование, привязать приложение к маркету после восстановления (для дальнейших обновлений). Удобная функция — создание на основе бэкапа приложений и данных архива update.zip, который можно прошить из консоли восстановления, чтобы восстановить приложения и настройки.

Одно из наиболее полезных применений Titanium Backup — это перенос приложений и их настроек между устройствами. В качестве примера покажу, как заставить работать популярный мессенджер WhatsApp на планшете без сим-карты. При поиске программы в маркете на странице с описанием будет указано, что данная программа не поддерживается на твоем устройстве. Даже если скачать и установить APK, для активации программы необходим дозвон на устройство, чего планшет без симки (или LTE с тарифом без голосовых вызовов или выпиленным из прошивки дайлером) сделать не сможет.

Итак, заходим в Titanium, ищем нужное приложение, нажимаем на него и во всплывающем меню нажимаем «Сохранить». Если в меню сделать свайп влево, то можно вызвать дополнительные функции. Это же меню можно вызвать долгим тапом на приложении в списке. После отработки скрипта в панели уведомлений появится новая запись о создании успешного бэкапа. Для удобства работы советую настроить в программе загрузку бэкапов в облако. Синхронизацию можно настроить на третьей вкладке — «Расписания». Нажимаем «Пуск» на пункте «Синхронизация с Google Диск», и об успешном выполнении сообщит уведомление в шторке.

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

Titanium Backup: бэкап и восстановление на другом устройстве
Helium — App Sync and Backup

Главное отличие программы — возможность работать без наличия прав суперпользователя (приложение использует стандартный backup manager, доступный в любом Android начиная с версии 4.0. — Прим. ред.). При этом часть функций урезана и требуется приложение-компаньон на компе. Программа позволит сделать бэкап пользовательского словаря, сообщений и журналов звонков, точек доступа Wi-Fi. Системные приложения нельзя бэкапить, даже если есть рут. Также резервирование может быть запрещено разработчиками некоторых программ. Они будут находиться внизу списка. Например, тот же WhatsApp забэкапить не получится.

Helium запоминает все устройства, на которых она была запущена, и позволяет восстанавливать бэкапы отдельно на разных устройствах. Бэкапы можно хранить на карте памяти или в облаке (Google Диск, Box, Dropbox), а также делать их по расписанию. Еще одна особенность приложения — данные между устройствами легко переносить, например, начав игру на одном устройстве, можно продолжить ее на другом.

IMEI

Нередки случаи, когда после прошивки перестает работать сотовая связь и интернет. Это верный признак того, что слетел IMEI (International Mobile Equipment Identity — международный идентификатор мобильного оборудования). Этот номер уникален для каждого аппарата и служит для идентификации устройства в сети. При сбое он может обнулиться, и девайс перестанет видеть сеть.

Чтобы избежать таких случаев, советую заранее сделать бэкап раздела EFS, содержащего IMEI: с помощью программ из маркета, руками через консоль (adb shell) или на устройстве через эмулятор терминала. Стоит отметить, что для разных устройств таблица разделов может кардинально отличаться в зависимости от применяемых чипов. В случае Nexus 4 в терминале нужно ввести следующие команды:

Бэкап IMEI:

su
 dd if=/dev/block/mmcblk0p8 of=/sdcard/m9kefs1.img
 dd if=/dev/block/mmcblk0p9 of=/sdcard/m9kefs2.img

Восстановление IMEI:

su
 dd if=/sdcard/m9kefs1.img of=/dev/block/mmcblk0p8
 dd if=/sdcard/m9kefs2.img of=/dev/block/mmcblk0p9

У Nexus 5 нет отдельного раздела EFS. Поэтому бэкапить надо разделы 12 и 13, содержащие не только IMEI, но и другие данные:

su
 dd if=/dev/block/mmcblk0p12 of=/sdcard/modemst1.img
 dd if=/dev/block/mmcblk0p13 of=/sdcard/modemst2.img

Восстановление проводится аналогичной командой.

 

Фотографии и видео

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

Google+

Стандартная программа от «корпорации добра», предустановленная на всех стоковых прошивках. Пользуюсь давно и на всех устройствах (на данный момент в альбомах содержится более 10 тысяч фотографий). Автоматически синхронизирует все отснятые фото с закрытыми альбомами Picassa (скоро такая же функция появится и в Google Drive). Фото будут доступны на всех устройствах, на которых выполнен вход в один аккаунт. При наличии интернета все фото можно просмотреть даже на новом устройстве, выполнив вход в аккаунт Google. Приятный бонус — автокоррекция некоторых фотографий, создание коллажей из похожих фото и GIF-анимаций из серий фотографий. Также автоматически появляются «Автокреативы» — нарезка под музыку из множества фотографий и видео, снятых в один день. При смене места снятия фотографий и видео обычно появляются «Истории» и «Путешествия».

Другие варианты
  • MEGA — дает по умолчанию хранилище на 50 Гб, имеет гибкие настройки, клиент синхронизации для компа и расширение для браузера Chrome. Разные режимы просмотра, возможность открыть папки для других пользователей.
  • Облако Mail.ru — 100 Гб для новых пользователей. Имеет приятный интерфейс и клиент для компа.
  • Dropbox — интересен тем, что имеет приложение-компаньон Carousel, которое умеет не просто автоматически загружать фотки, но и чистить смартфон от тех, что уже загружены.
Настройки автозагрузки Google+, Mega, Облако Mail.ru
INFO

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

 

Бэкап произвольных файлов

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

Foldersync

Material Design, поддержка Amazon Cloud Drive, Box, Dropbox, FTP, Google Drive, Mega, OneDrive, SMB/CIFS, WebDav, Yandex Disk. Имеет встроенный файловый менеджер, множество настроек, фильтров, удобное планирование. Возможность настройки двухсторонней синхронизации, перенос скрытых файлов, настройка передачи через Wi-Fi / мобильный интернет, поддержка Таскера, защита пин-кодом, возможность синхронизации вложенных папок.

DataSync

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

Dropsync

Продвинутый клиент синхронизации с Dropbox. Загрузка фото и видео, мониторинг уровня заряда батареи, Wi-Fi/3G/4G/WiMax-соединения и адаптация в соответствии с предпочтениями пользователя, настраиваемый интервал автосинхронизации, плагин к Таскеру, возможность выбора режима синхронизации: только загрузка, загрузка и удаление, только скачивание, зеркальное скачивание и другое.

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

Настройки Foldersync, DataSync, Dropsync
INFO

Для Linux/UNIX-пользователей подойдет rsync backup for Android, которая позволит отправлять и получать файлы с удаленного сервера через SSH. Имеет поддержку Таскера.

 

Полный бэкап устройства

Nandroid backup (от NAND — тип используемой памяти в современных смартфонах) — полный бэкап всей прошивки целиком вместе с приложениями, данными и настройками. Функция поддерживается TWRP или CWM. Кроме того, бэкап можно сделать и прямо из Android с помощью программы Online nandroid backup. Восстановить отдельные данные поможет уже рассмотренный Titanium, а также Nandroid manager. Сначала посмотрим, как сделать бэкап из консоли восстановления.

CWM

Для создания бэкапа необходимо выбрать пункт Backup and Restore, а затем Backup to /sdcard. До нажатия можно выбрать формат бэкапа или освободить неиспользованные данные. Для восстановления выбираем пункт Backup and Restore и далее Restore from /sdcard. Если выбрать Advanced restore from /sdcard, можно указать для восстановления отдельно разделы boot, system, data, cache, sd-ext.

Для большей сохранности полученный бэкап можно перенести на комп. Но здесь есть одна загвоздка. Дело в том, что, если в устройстве есть «внешняя» (настоящая) карта памяти, CWM разместит бэкап в ней и он будет доступен для сохранения на комп стандартными средствами (каталог clockworkmod/backup/дата-и-время-бэкапа на карте памяти). Здесь все в порядке.

Лирическое отступление, или признание в любви к устройствам Nexus

Если посмотреть на структуру разделов Nexus-устройств с помощью команды adb shell busybox fdisk /dev/block/mmcblk0 (нужен root и установленный из маркета BusyBox), то можно увидеть следующую картину (см. скриншот «Структура разделов на Nexus 5 и Nexus 4»).

Раздел aboot — это первичный бутлоадер. Его можно повредить, если, например, прошить ядро или бутлоадер от другого устройства или выдернуть шнур из телефона в процессе прошивки. При этом слетает таблица разделов и телефон перестает грузиться в бутлоадер и рекавери, а также перестает откликаться на команды fastboot и adb.

Обычный юзер думает, что это «кирпич», и несет телефон в сервисный центр, где платит больше ста долларов за новую взамен якобы сгоревшей плату. На самом же деле в разделе 15 у Nexus 4 и разделе 11 у Nexus 5 находится резервная копия бутлоадера — abootb. Это одна из причин того, что убить Nexus практически невозможно, ведь резервный загрузчик можно без проблем восстановить.

Выключаем смартфон и включаем с одновременным нажатием клавиш <Vol Up + Power>. Затем одновременно нажимаем и удерживаем комбинации кнопок <Vol Up + Vol Down + Power> (сработает, только если убит основной загрузчик). После этого подключаем устройство к компу (теперь оно определится и ADB заработает) и копируем резервный загрузчик в раздел основного командами

$ adb shell
 su

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

Однако в смартфонах без слота для карты памяти или при ее отсутствии бэкап окажется невидим для пользователя. Это происходит из-за того, что с версии 4.2 в Android изменились точки монтирования внутренней памяти для обеспечения работы в многопользовательском режиме. Сама виртуальная (внутренняя) карта памяти монтируется в /data/media, и там же находится бэкап CWM. Но данные основного пользователя находятся в /data/media/0, и именно этот каталог затем монтируется как /sdcard. Поэтому бэкап останется недоступен с помощью стандартных средств и без прав root.

Достать бэкап из /data/media можно с помощью файлового менеджера с правами суперпользователя или путем подключения смартфона к компу в режиме recovery. Далее вводим команду adb shell, а затем ls /sdcard/clockworkmod/backup/ для поиска каталога с последним бэкапом. Переносим бэкап примерно такой командой:

$ adb pull /sdcard/clockworkmod/backup/2015-04-20.15.46.18 \
 "D:\Nexus5\Backup\Nandroid\2015-04-20.15.46.18"

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

TWRP

Для создания бэкапа нажимаем кнопку Backup и крестиками отмечаем необходимые разделы (не уверен — выбирай все). Дополнительно можно убрать шифрование, включить сжатие, пропустить создание MD5-хеша и выбрать сохранение на USB — OTG флешку. В результате бэкап окажется в каталоге /sdcard/twrp/backups/дата-и-время-бэкапа. В отличие от CWM он будет доступен независимо от наличия карты памяти. Для восстановления нажимаем Restore и выбираем нужный.


INFO

В маркете есть большое количество программ для отдельного бэкапа и восстановления СМС, звонков, контактов, ядер, рекавери и так далее.

Nandroid Manager

Это универсальный инструмент для управления всеми резервными копиями Nandroid. С помощью Nandroid Manager можно восстановить из Nandroid приложения и данные, СМС, журнал вызовов, точки доступа Wi-Fi, сохраненные сопряженные устройства Bluetooth, пользовательский словарь. Приложение видит бэкапы, созданные в обоих кастомных рекавери, и позволяет их переименовывать и искать информацию в отдельных базах внутри бэкапа.

Возможности Nandroid Manager

 

Online nandroid backup

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

  • Имя бэкапа — каждый раз вручную / по временной зона UTC / по временной зоне телефона / на основе номера версии прошивки, включая время создания.
  • Тип бэкапа — CWM/TWRP со сжатием или без.
  • Режим — нормальный (полный) / выбор разделов для копирования. При выборе последнего открывается список с выбором.
  • Место сохранения бэкапа.
  • Количество бэкапов для хранения от «все» до 10 (при переполнении более старые удаляются).
  • Сохранение разделов Yaffs2 в качестве Tar-файлов.
  • Исключение Dalvik Cache из бэкапа.
  • Исключение файлов Google Music из бэкапа.

Программа поддерживает выгрузку файлов бэкапа в облако, FTP или Google Drive. Доступно настраиваемое расписание для автоматических бэкапов, от «каждый день» до «каждые 30 дней» с опцией «только когда устройство заряжается». Кроме того, с помощью плагина поддерживаются действия для Tasker.

 

Бэкап с помощью ADB

Способ, так сказать, для гиков. Подключаем смартфон к компу, включаем отладку по USB. Далее используем команду adb backup, которая имеет следующие ключи:

  • -f ФАЙЛ — место и название файла создаваемого бэкапа на компьютере. Если нет этого параметра, бэкап будет создан в текущей папке с названием backup.ab. В случае Windows пути с пробелами и спецсимволами следует заключать в кавычки.
  • -apk | -noapk — сохранять или нет в бэкапе APK-приложения. По умолчанию — не сохранять.
  • -system | -nosystem — сохранять ли в бэкапе системные приложения. По умолчанию — сохранять. Выбор -nosystem запретит сохранять системные приложения, когда задан ключ -all.
  • -all — сохранять в бэкапе все установленные приложения, в том числе системные.
  • -shared | -noshared — включать ли в бэкап данные приложений и содержимое карты памяти. По умолчанию — не сохранять.
  • — здесь можно написать список приложений, которые будут бэкапиться. Игнорирует —nosystem.

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

$ adb backup -f "D:\Backup\ADB-2015-04-20.ab" -apk -shared -all -system

После этого в консоли появится Now unlock your device and confirm the backup operation, а на телефоне уведомление с просьбой подтвердить операцию и установить опциональный пароль на бэкап. Сам процесс создания резервной копии может длиться больше сорока минут, так что нервничать не надо. Для восстановления используем команду «adb restore путь-до-файла», для примера выше это будет:

$ adb restore "D:\Backup\ADB-2015-04-20.ab"

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

INFO

Узнать номера IMEI, всех своих устройств, привязанных к Google (в том числе старых), можно на странице google.com/settings/dashboard, раскрыв список Android.

 

Заключение

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

Как делать бэкап. Что такое резервное копирование.

Что такое бэкап

Что такое бэкап (backup) и зачем он нужен?

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

Как часто нужно делать резервную копию (бэкап)?

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

Куда лучше делать резервную копию?

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

Облачные технологии резервного копирования

Частичные копии информации можно делать на такие сервисы как Google диск, или Яндекс диск. Там есть ограничение по размеру загружаемых объемов 10-15 Gb, но зато то все бесплатно. Сохраните самые важные фотографии и воспоминания на «облако».

Для продвинутых пользователей и опытных специалистов есть специальные программы для бекапа например Acronis. Зачем же нужно использовать программу, если можно просто скопировать с одного жесткого диска на второй? Дело в том, что можно сделать резервную копию Windows и всех установленных программ и хранить до тех пор, пока не слетит теперешняя виндовс. Просто использовав эту программу и сохраненный ранее бэкап локального диска где был установлен windows и программами вы за пару минут восстанавливаете операционную систему.  Если для Вас эта информация актуальна, в комментариях вы можете попросить написать статью как именно все это происходит, мы это сделаем.

Часто просматриваемое:

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

Fullcartridge2019-02-26T17:41:07+02:00

Назначение, обзор методов и технологий / Southbridge corporate blog / Habr

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

—Жан Брюлер

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

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

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

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

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

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

— Есть два вида системных администраторов, те кто не делает резервные копии, и те, кто УЖЕ делает.
— На самом деле три вида: есть еще те, кто проверяет, что резервные копии можно восстановить.

—Неизвестный

Также стоит понимать, что сам процесс резервного копирования данных осуществляется программами, поэтому ему присущи все те же минусы, как и другой программе. Чтобы убрать (не исключить!) зависимость от человеческого фактора, а также особенностей — которые по отдельности не сильно влияют, но вместе могут дать ощутимый эффект, — применяют т.н. правило 3-2-1. Есть много вариантов, как его расшифровать, но мне больше нравится следующая трактовка: хранить надо 3 набора одних и тех же данных, 2 набора надо хранить в разных форматах, а также 1 набор надо иметь на географически удаленном хранилище.

Под форматом хранения следует понимать следующее:

  • Если есть зависимость от физического способа хранения — меняем физический способ.
  • Если есть зависимость от логического способа хранения — меняем логический способ.

Для достижения максимального эффекта правила 3-2-1 рекомендуется менять формат хранения обоими способами.

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

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

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

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

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

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

Quis custodiet ipsos custodes?

(Кто устережет самих сторожей? — лат.)

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

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

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

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

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

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

Знает толк в пряностях не тот, кто добавляет их в каждое блюдо, но тот, кто никогда не добавит в него ничего лишнего.

—В. Синявский

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

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

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

  • dd, знакомая ветеранам системного администрирования, сюда же относятся схожие программы (та же dd_rescue, например).
  • Встроенные в некоторые файловые системы обслуживающие программы (утилиты), создающие слепок (dump) файловой системы.
  • Всеядные утилиты; например, partclone.
  • Собственные, зачастую собственнические, решения; например, NortonGhost и более поздние.

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

  • Rsync, универсальную программу и протокол для синхронизации состояния файловых систем.
  • Встроенные средства для архивации (ZFS).
  • Сторонние средства для архивации; самый популярный представитель — tar. Есть и другие, например, dar — замена tar с ориентацией на современные системы.

Отдельно стоит упомянуть о программных средствах обеспечения консистентности данных при создании резервных копий. Чаще всего применяют следующие варианты:
  • Монтирование файловой системы в режим только чтение (ReadOnly), или замораживание файловой системы (freeze) — метод применим ограниченно.
  • Создание слепков состояния файловой систем или блочного устройства (LVM, ZFS).
  • Применение сторонних средств для организации слепков, даже в тех случаях, когда предыдущие пункты не могут быть обеспечены по каким-либо причинам (программы вида hotcopy).
  • Техника копирования при изменении (CopyOnWrite), однако она чаще всего привязана к используемой ФС (BTRFS, ZFS).

Резервное копирование (backup)– что это и зачем оно нужно?

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

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

Зачем оно нужно? Конечно же, для сохранности ваших данных. С одной стороны, современные компьютеры вообще, и жесткие диски в частности, являющиеся основным и самым популярным способом хранения информации, в настоящее время достигли весьма впечатляющих показателей надежности. Всевозможное кодирование с избыточностью на разных уровнях работы с данными обеспечивает надежную защиту от того, что данные будут испорчены в результате случайной ошибки во время записи. Но вот беда, любой, даже самый надежный носитель информации рано или поздно выходит из строя, и, что самое неприятное, делает это обычно внезапно. И вот тут уже совсем по-другому начинаешь относиться к той уйме информации, которая у любого современного человека хранится на диске. Пароли и контакты, памятные фотографии и коллекция редкой музыки, всевозможные рабочие данные – все это богатство внезапно исчезает, что оборачивается серьезными финансовыми, временными и моральными убытками. Порой, это удается восстановить, отнеся погибший диск в фирму, занимающуюся восстановлением информации, но далеко не всегда там способны сотворить чудо. Например, статистика компании derstein, занимающейся восстановлением данных, гласит, что лишь 22 % данных удается вернуть.  Конечно, существует еще такая вещь, как массивы с зеркалированием (RAID1), но и они не гарантируют сохранность информации. Да, данные на таких массивах защищены он гибели носителя, но они абсолютно не защищены от ошибок пользователя или системных сбоев, ведь последние окажут воздействие сразу на оба диска массива. Как тут не вспомнить о многочисленных вирусах! А ведь есть еще и непредвиденные ситуации, когда страдает сразу весь компьютер – ноутбук можно уронить или потерять, а домашний компьютер может стать жертвой детей или просто соседей, заливших вашу квартиру. Самое надежное средство против всех этих напастей – регулярное создание резервных копий данных.

Самый простой вариант – простое копирование своими руками данных в другую папку на жестком диске. Увы, он является и весьма трудоемким и самым ненадежным, поскольку защитит лишь от части возможных проблем,  даже если эта папка расположена на другом диске. Самым защищенным вариантом является создание копий, расположенных на удаленном сервере в интернете, но для большинства этот путь слишком сложен. Наиболее удачным вариантом с точки зрения простоты, удобства и защищенности является создание копий на внешнем накопителе, с сетевым интерфейсом или интерфейсом USB. Компания Western Digital уже длительное время предлагает в своих продуктах готовое комплексное решение: вместе с внешними накопителями поставляется специализированное ПО, требующее лишь минимальной стартовой настройки и дальше выполняющее все автоматически. Так, для популярных серий WD Passport таким ПО является программа WD SmartWare – она автоматически отслеживает изменения важных для вас файлов и при необходимости копирует их на подключенный накопитель, не требуя вашего особого внимания.

 

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


Что такое бэкап (backup)?! | Как настроить?

Что такое бэкап?!

Если Вы общались среди Айтишников, то скорее всего у них в разговоре хоть раз, но промелькнуло слово «Бэкап». Что же это за слово? Backup в мире цифровых технологий является сокращением от фразы «backup copy», что переводится на великий и могучий, как «Резервное копирование».
Другими словами, Бэкап может быть как процесс создания копии данных жёстком диске, DVD или флешке USB, которая будет использоваться в дальшнейшем для восстановления данных в случае повреждения или разрушения оригинала. Так же, по Backup’ом могут понимать и сам файл или архив резервной копии данных. 


Бекап может быть создан разными способами:

— Клонирование оригинального носителя в виртуальный образ (например, ISO) или на резервный накопитель
— Полное копирование оригинальный данных в архив или съёмный носитель (Full Backup)
— Копирование только важных файлов на носитель.

Куда можно сохранить Backup:
В зависимости от объёма данных это может быть:
— CD/DVD/BlueRay Диск
— USB-накопитель (флешка или жесткий диск)
— Жесткий диск HDD
— Сервер в локальной сети или интернете, на котором хранятся бэкапы системы, диска и .т.п., копирование на который осуществляется по протоколам Samba или FTP
— Облачные серверы (Яндекс.Диск, DropBox, Google Drive, iCloud и т.п.)
Вовремя сделанный файл резервной копии или Backup-файл может сэкономить уйму времени системному администратору. Ведь одно дело скопировать уже «готовые к употреблению» данные, нежели создавать это всё заново с нуля! Главное соблюдать следующие правила создания резевных копий:
— Копий должно быть несколько;
— Создавать бэкапы (системы, сервера, прошивки, диска и т.п.) надо с определённой периодичностью, которая зависит от степени важности файлов и частоты их обновления;
— Храните копии в разных местах, дабы избежать риска их утраты или повреждения всех сразу;
— Позаботьтесь о безопасности резервных файлов.


Поделитесть полезным с друзьями:

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

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

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

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

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

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

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


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

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

Бэкап

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

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

Бэкап данных

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

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

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

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

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

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

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

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


Обзор UrBackup.

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


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

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


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

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


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


Обзор BackupPC

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


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


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


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

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


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


Обзор AMANDA

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


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


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

Анонс

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

что такое бэкап и как его делать?

Бэкап (англ. "backup") - это резервное копирование файлов с целью их последующего восстановления. Например, бэкап файлов при переустановке операционной системы. Чтобы не потерять файлы, вы можете: а) скопировать их на другой раздел (другой логический диск) ; б) скопировать их на переносное устройство (например, флешку) ; в) синхронизировать их с облачными сервисами хранения файлов (например, Dropbox или Ubuntu One).

Бекап-резервная копия программы. Открываешь опцию Восстановление, далее по подсказкам компьютера.

бэкап-копия файлов на другой носитель информации

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

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

бэкап -Это резервная копия.

типо резервная копиЯ программы почитай в вики !

а каой ты имел в виду?! внешний жесткий диск?! или делаешь резрвную копию с помощьакнориуса или паргона только когда качаешь эти программы смотришь подходит они к твоей оппрационой ситеме!!!

да поставьте Syncovery и не парьтесь.

где найти бекап на китайфоне s4 i9500 подделка.

Бэкап файлов - это создание резервной копии файлов (копирование) с целью их восстановления в случае потери, например, порчи вирусом, случайного удаления и других неприятностей. Вот есть такая простая бесплатная утилита Exiland Backup, рекомендую ее скачать и попробовать в действии. Достаточно один раз указать ей какие папки и куда копировать (желательно на внешний винчестер, флешку или FTP-сервер) и по какому расписанию, например, раз в сутки в 20:00. Готово. Все остальное программа сделает сама. <a href="/" rel="nofollow" title="37624337:##:https://exiland-backup.com/ru/">[ссылка заблокирована по решению администрации проекта]</a> <img src="//otvet.imgsmail.ru/download/2493530_395c5c20863276e9584554462abad05b_800.gif" alt="" data-lsrc="//otvet.imgsmail.ru/download/2493530_395c5c20863276e9584554462abad05b_120x120.gif" data-big="1">

Бэкап - это резервирование чего-либо, в сети Интернет чаще всего подразумевается бэкап файлов, сайтов, vds и серверов. Самый надежный способ это создавать резервные копии не локально, а удаленно, но многим владельцам сайта некуда делать такие резервные копии. Я нашел сервис <a rel="nofollow" href="https://go.backupland.com" target="_blank">https://go.backupland.com</a>, мне он понравился тем что не только бэкапятся на их сервера, независимо от моего хостинга, но и ещё ежедневно проверяются на вирусы, плюс по акции на странице: <a rel="nofollow" href="https://go.backupland.com/actions/actions_free.html" target="_blank">https://go.backupland.com/actions/actions_free.html</a> можно получить бесплатно на год один из их тарифов. Всем удачи. <img src="//otvet.imgsmail.ru/download/245924661_0ce44f8586110b132c056420fdcc6b68_800.png" alt="" data-lsrc="//otvet.imgsmail.ru/download/245924661_0ce44f8586110b132c056420fdcc6b68_120x120.png" data-big="1">

Безопасное резервное копирование с помощью публичных сервисов / Habr


Часто бывает так, что существует множество различных проектов, которые необходимо регулярно бэкапить.
Но еще чаще бывает так, что поднимать свой собственный сервис резервного копирования лениво, и копии в лучшем случае делаются время от времени, а в худшем — не делаются вообще. Специально для ленивых людей придумали сервисы синхронизации файлов, такие как Dropbox, Yandex.Disk и иже с ними. Суть всегда одна: файл, загруженный на одном привязанном устройстве, появляется на всех остальных. Ура, решение найдено.
Но встает другой вопрос: безопасность загруженного контента. И если за фотки с Майорки можно особо не переживать, то боевую базу 1С так бэкапить чревато. И вот тут, в этой самой статье, есть небольшой HOW-TO про то, как остаться лентяем и сохранить файлы в безопасности.
Предположения

При написании этого HOW-TO я предполагаю, что читатель знаком с основами системного администрирования, может самостоятельно создать аккаунт и настроить сервис синхронизации на удаленном компьютере. Я буду показывать на примере CentOS 6 Linux, своих узлов и сервиса Dropbox. Все тоже самое можно сделать и на других ОС и сервисах. И даже вместо GnuPG можно использовать OpenSSL.
Установка софта на хранилище

Установка и настройка Dropbox

Качаем и ставим. Кстати, несмотря на то, что в зависимостях есть X11, можно спокойно ставить с --nodeps
[root@server ~]# wget https://www.dropbox.com/download?dl=packages/fedora/nautilus-dropbox-1.6.0-1.fedora.x86_64.rpm [root@server ~]# rpm -i --nodeps nautilus-dropbox-1.6.0-1.fedora.x86_64.rpm Dropbox installation successfully completed! You can start Dropbox from your applications menu. [root@server ~]# su user [user@server ~]$ dropbox start -i Downloading Dropbox... 100% Unpacking Dropbox... 100% Done! [user@server ~]$ dropbox stop [user@server ~]$ ~/.dropbox-dist/dropboxd This computer isnt linked to any Dropbox account... Please visit https://www.dropbox.com/cli_link?host_id=**************************************** to link this device. This computer isnt linked to any Dropbox account... Please visit https://www.dropbox.com/cli_link?host_id=**************************************** to link this device.

Переходим по ссылке, вводим пароли, и вот:
This computer is now linked to Dropbox. Welcome ********* ^C ~/.dropbox-dist/dropboxd & [user@server ~]$ exit [root@server ~]# rpm -e nautilus-dropbox

Установка GNUPG2 и создание ключей
[root@server ~]# yum install gpg [... skipped ...] [root@server ~]# su user

Создаем пару ключей
[user@server ~]$ gpg --gen-key [... skipped ...] Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) Key does not expire at all Is this correct? (y/N) y GnuPG needs to construct a user ID to identify your key. Real name: Backup Server Email address: [email protected] Comment: Main backup server You selected this USER-ID: "Backup Server (Main backup server) <[email protected]>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O You need a Passphrase to protect your secret key. [... skipped ...] gpg: key E4E021AB marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u pub 4096R/E4E021AB 2014-01-29 Key fingerprint = 0FDC B999 6FEB FBB5 1E59 48BD 71C2 6663 E4E0 21AB uid Backup Server (Main backup server) <[email protected]> sub 4096R/C7212824 2014-01-29

Если при генерации gpg будет ругаться, что не хватает энтропии, создайте её.
Я обычно захожу в другую консоль и делаю что-то вроде: 
[user@server ~]$ while true; do find / -type f; done

Осталось только расшарить публичный ключ между всеми участниками — кладем его в Dropbox.
[user@server ~]$ gpg --export -o ~/Dropbox/public.gpg

Установка софта на резервируемом сервере

В принципе, все тоже самое, но свои ключи можно не генерировать.
Достаточно сделать 
[user@server ~]$ gpg --import ~/Dropbox/public.gpg
Процесс резервного копирования

Можно по-разному. У меня у каждого сервера есть свой dropbox-аккаунт, и папка, которая является общей (Shared folder) с бэкап-сервером. Типа backu_srv1, backup_srv2 итд. Хотя можно просто иметь 1 аккаунт на все сервера — всё зависит от объемов данных, которые будут резервироваться.
Главная «фишка» — шифрование файлов перед тем, как положить их в Dropbox.
Ниже — пример скрипта, бекапящего базу данных mysql.
#!/bin/sh FILE="~/Dropbox/backup_srv1/mysql_$(date +%d.%m.%y).sql.gz.gpg" LOG="~/scripts/backup.log" USER="************" PASS="************" DB="**********" KEY="0xE4E021AB" export PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl mysqldump -u${USER} -p${PASS} $DB|gzip -c|gpg --trust-model=always --yes -e -r $KEY -o "$FILE" && echo "$FILE : OK" >> "$LOG" && exit echo "$FILE : ERROR" >> "$LOG" && exit

Обратите внимание на KEY — это ID публичного ключа, который мы получили в пункте 2 и импортировали в/на сервер.

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

Дальнейшее использование бэкапов

Возможны варианты. Можно расшифровывать все полученные бэкапы и складывать их куда-нибудь, можно хранить зашифрованными до часа «Х». Это дело вкуса. Единственное, что я рекомендую — это иметь несколько копий приватного ключа, в том числе на листочках A4 в конверте в сейфе. Если все остальные варианты потеряете — будете набивать с листочка много-много символов.
[user@server ~]$ gpg --armor --export-secret-keys

Ах, да. Сама расшифровка.

[user@server backup_srv1]$ gpg -o ~/mysql_29.01.14.sql.gz -d mysql_29.01.14.sql.gz.gpg Необходима фраза-пароль для доступа к секретному ключу пользователя: "Backup Server (Main backup server) <[email protected]>" 4096-бит RSA ключ, ID C7212824, создан 2014-01-29 (главный ключ ID E4E021AB) gpg: зашифровано 4096-битным ключом RSA, с ID C7212824, созданным 2014-01-29 "Backup Server (Main backup server) <[email protected]>"

А теперь — важная вещь:
Не расшифровывайте свои бэкапы в папки, которые синхронизируются с Dropbox!
Вместо заключения

Если вы, прочитав эту статью, побежали регистрировать аккаунт на каком-нибудь сервисе и генерировать ключи, значит вы из тех, кто уже делает бэкапы. Поздравляю!
Если же вам всё еще лениво — не отчаивайтесь, вас ждет отличный опыт и много адреналина. Когда-нибудь.
А если вам захотелось узнать, что еще умеет делать gnupg — можете заглянуть сюда

—
8033A3EF/DBD1 B794 73AD 3A5C 9279 A8E1 16B5 6AA3 8033 A3EF

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