Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 837 сообщений
Cообщения с меткой

резервное копирование - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

Veeam Backup & Replication: workaround для одной проблемы с метаданными backup job

Вторник, 10 Мая 2016 г. 23:36 (ссылка)

Disclaimer практически

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

0. Большому количеству уважаемых многоопытных коллег всё это покажется мелким и не заслуживающим внимания. Facil omnes, cum valemus, recta consilia aegrotis damus.

1. Какому-то — пусть и небольшому — количеству уважаемых менее опытных коллег будет полезно/нужно/небезынтересно.

2. Намёки на приспособление для поддержания веса тела пациента при стоянии и ходьбе имеют право на существование, поскольку workaround он потому и workaround.

3. Гугль не знает или я плохо искал. Но честно старался.

4. Опыт в написании чего-то подобного первый, отсюда и комки в текстуре.



Приветствую, уважаемое сообщество.



Преамбула



В инфраструктуре нашей компании существует три параллельных ветви серверов Veeam B&R. Ветви, как у нас любят объяснять практически любые казусы, «исторически сложились».



Одна обслуживает backup job'ы медленно сходящей на нет фермы виртуализации, оставшейся после слияния компаний.

Вторая была опытно-промышленным внедрением Veeam B&R, плавно ставшим решением промышленным и на данный момент обслуживает backup и replication job фермы виртуализации vSphere 4.1 (да, всё ещё в эксплуатации, извините) и backup job фермы виртуализации vSphere 5.5.

Третья обслуживает исключительно replication job' и failover plan'ы фермы виртуализации vSphere 5.5.

Всё это находится в процессе живой и непрекращающейся миграции.

Честь и счастье администрировать всё это богатство в течение последних ~5 лет выпала мне, как основному администратору виртуализации VMware vSphere, Veeam B&R и серверов Wintel.

+ Есть коллега на роли администратора запасного.







В ходе недавней подготовки к тестированию DR-решения, основанного на репликации виртуальных серверов средствами Veeam B&R, было выявлено непонятное нам несоответствие между количеством виртуальных серверов, входящих в состав backup и replication job'ов и сведениями о количестве точек восстановления у этих серверов.

Сведения о количестве точек получались через powershell с использованием Veeam Backup & Replication Powershell snapin.

Выборочная проверка количества точек запросом через веб-интерфейс Veeam Backup Enterprise Manager показала аналогичное расхождение с реальностью.

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

Да и беспокоит, зудит — ну не аккуратненько же. Надо починить.



Запасной администратор в данный момент тренируется с ТП Veeam по открытому кейсу, исследуя проблему в рамках replication job'ов.

Я решил покопаться в части backup job'ов на другой ветви Veeam B&R дабы не искажать картину, исследуемую ТП вендора.



Момент возникновения расхождений и их причины пока для нас неясны. При точном ответе от ТП Veeam внесу апдейт в текст.



Пока я для себя принял рабочую гипотезу, что неоднократные in-place upgrad'ы Veeam B&R начиная с версии 7 до текущей версии 9 update 1, неоднократные изменения настроек существующих job'ов и т.п. процессы не прошли даром и, предположительно, БД Veeam B&R накопила «мусора», дублирующихся записей в таблицах.

В качестве СУБД используется MS SQL, теоретически можно порыться в структуре базы, но, перефразируя Арамиса, "… но, право, я не DBA...".



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

Приведу пример:

Некий виртуальный сервер имярек входит в состав задания Veeam Backup & Replication. Согласно сведениям, отдаваемым Veeam Backup Enterprise Manager’ом, имеет 36 точек восстановления.





При этом свойства backup job'а в части количества хранимых точек не изменялись никогда – т.е. от момента создания job’а ещё в версии Veeam B&R 7 – и всегда было равно 7 для описываемого задания.

Раскрываемый список 36 restore point’ов выглядит вполне «рабочим» — никаких fail'ов, unaccessible-частей или чего-то ещё, наводящего на мысли о порче проблемах с точками, не видно:








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

КМК, при попытке восстановления был бы fail, поскольку физически в репозитории лежит 1 full backup, 6 incremental backup’ов и файл метаданных — то есть в наличии реально 7 точек, отсчитывая от текущего дня. Для 10 мая самая ранняя хранимая точка была бы создана 3 мая. А всё, что по датам создано раньше, реально не существует и живёт только в БД Veeam B&R.

Вот содержимое репозитория для рассматриваемого backup job'а:





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





Большинство заданий имеют файлы бекапа такого размера, что переносить их просто некуда + N ТБ архивов копироваться будут длительное время, задание на это время нужно остановить, а простой бекапов недопустим. Поэтому вариант с переносом файлов бекапа на другой репозиторий с последующим выполнением rescan repository и map backup в настройках задания не был принят как лучший выход из положения. По той же причине нельзя всё удалить, поставить заново, восстановив настройки Veeam B&R из регулярно создаваемой резервной копии.



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



И, пусть не слишком изящный, но он был нащупан.

Алгоритм примерно следующий:



1. В репозитории, содержащем файлы бекапа, меняем расширение в имени файлов

— full backup

— backup chain metadata file

Note. Переименование / перенос на другой репозиторий одного backup chain metadata file с последующим rescan'ом репозитория не помогает.





2. Выполняем Rescan для репозитория, содержащего файлы бекапа. Видим, что один бекап был удалён из базы.





3. Возвращаем расширение в имени файлов full backup и метаданных в репозитории на исходную позицию.



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





5. Проверяем виртуальный сервер имярек ещё раз и видим количество точек восстановления, соответствующее настройкам задания и количеству файлов в репозитории.





Повторюсь, что решение далеко от изящества. При большом количестве job’ов существенно большем от примерно 70 в моём случае пришлось бы искать иной способ — от скриптов до переустановки сервера Veeam B&R.



Приветствуется тыкание носом в не найденные решения, kb, мнения, предложения так далее — fas est et ab hoste doceri.





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/283276/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Установка CrashPlan в Docker-контейнер на NAS Synology

Среда, 27 Апреля 2016 г. 15:37 (ссылка)





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



Прелюдия



Большие домашние хранилища от Synology усыпляют бдительность. Они кажутся надежными и безотказными. Там есть RAID, который защищает от сбойных дисков. Там есть «Time Backup», который отлично сохраняет версии файлов и позволяет их легко восстанавливать. Однако, настоящие параноики, чтущие Нассима Талеба, всегда помнят о редких, но неприятных событиях, которые могут случится с вашими данными, да и самим хранилищем:




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

  • Шифрующие вирусы. Живой пример — вирус SynoLocker, доставивший пользователям много страданий. Он проникал через дыру в DSM (ОС от Synology, под управлением которой работает это сетевое хранилище). Шифровал там все файлы и вымогал деньги. Ну, всё как обычно.

  • Что-то ещё.



Исходя из этого, каждому здравомыслящему параноику понятно, что нужно прятать резервные копии всех важных данных (детские фотографии, например) подальше в облака. Разработчики это тоже понимают. В DSM есть пакет «Cloud Sync», который позволяет копировать ваши данные в удаленные облачные хранилища. К настоящему времени поддерживается много облачных сервисов:




  • Облачное хранилище Amazon, Amazon S3, Облачные сервисы, совместимые с Amazon S3, Baidu Cloud, Box, Dropbox (в том числе Dropbox for Business), Google Cloud Storage, Google Диск (в том числе Google Drive for Work), hicloud S3, HiDrive, hubiC, IBM SoftLayer, Megafon Megadisk, Microsoft OneDrive (в том числе Office 365 и OneDrive for Business), Облачные сервисы, совместимые с OpenStack Swift, Rackspace, Резервное копирование SFR NAS, WebDAV, Яндекс Диск.



Однако, по непонятной мне и многим пользователям причине, не поддерживается облачный сервис специально заточенный под резервное копирование — CrashPlan. Он любим за свою надежность, безлимитность и недорогие тарифы. Поэтому, долгое время сообщество прикручивает этот сервис к Synology скотчем и степлером. Так, Patrick Moore (мой герой!) с 2012 года поддерживал и постоянно допиливал свой пакет CrashPlan, работающий на хранилище. Но, похоже, в 2015 году он окончательно устал.



Шаги по спасению мира и запуску CrashPlan в Docker-контейнере на Synology



Пришлось поднять голову и оглядеться вокруг. К этому времени, на Synology появился Docker (не на всех версиях) и теперь есть возможность запустить CrashPlan в Docker-контейнере, где он будет успешно жить и самостоятельно обновляться. Его установка и настройка не вполне очевидны. Надеюсь, что короткая инструкция ниже поможет вам набить чуть меньше шишек, чем мне. Она скорее для чайников, ибо профессиональные linux-админы уже у себя дома давно всё настроили.



Итак, следующая последовательность действий, позволит вам запустить и управлять своим клиентом CrashPlan в Docker-контейнере, который бежит на Synology:



1. Создаем на своем хранилище новую папку общего доступа. Например: «crashplan-symlink». Именно эту папку будет видеть CrashPlan из контейнера. Она одна должна содержать все данные, которые будет обрабатывать CrashPlan. Можно переложить все важные данные непосредственно в неё, но лучше создать там подпапки «music-symlink», «photo-symlink», «homes-symlink» и определить их как симлинки на реальные папки хранилища. Это тоже работает.







2. Создаем на хранилище новый файл /etc/rc.local и прописываем в него команды для монтирования симлинков с настоящих папок (фото, видео, и пр.) на вложенные папки в нашей новой папке общего доступа. Файл «rc.local» нужно использовать потому, что иначе симлинки не выживают при перезагрузке хранилища. Если есть затруднения, см. ниже «Удобное управление файлами на хранилище». Вот, что у меня сейчас в этом файле:



mount --bind /volume1/bittorrentsync /volume1/crashplan-symlink/bittorrentsync-symlink
mount --bind /volume1/homes /volume1/crashplan-symlink/homes-symlink
mount --bind /volume1/music /volume1/crashplan-symlink/music-symlink
mount --bind /volume1/photo /volume1/crashplan-symlink/photo-symlink
mount --bind /volume1/public /volume1/crashplan-symlink/public-symlink


3. Ставим на Synology пакет «Docker». Далее запускаем его после установки, ищем в реестре контейнер crashplan («jrcs/crashplan» — hub.docker.com/r/jrcs/crashplan) и также устанавливаем его.







4. При начальном конфигурировании контейнера «jrcs/crashplan» важно запомнить предложенное соответствие портов (если выберем автонастройку) или вручную задать соответствие двух портов необходимых для работы и управления CrashPlan. Например, вот так: порт «4243» назначить на «32774», а «4242» на «32773». Открываем дополнительные настройки контейнера и там прикрепляем нашу созданную на первом шаге папку общего доступа «crashplan-symlink». Ставим ей в соответствие значение "/storage", так она будет доступна из докер-контейнера.





5. Перегружаем хранилище. Убеждаемся, что наши симлинки в папке «crashplan-symlink» выжили и работают. Запускаем в докере пакет «jrcs/crashplan». Если все правильно, то к данному моменту мы имеем запущенный и работающий докер-контейнер внутри которого уже успешно запущен и работает клиент CrashPlan. Однако, сам клиент ещё не настроен. Ему нужно сказать, что и откуда брать и куда копировать, а для этого нужно подключиться к клиенту, через специальное приложение CrashPlan (есть и для Win и для Linux). Однако, просто так подключиться к клиенту приложение не сможет, там все шибко безопасно, поэтому квест продолжается.







6. Для того, чтобы иметь возможность подключиться к клиенту CrashPlan, нужно вытащить из специального файла в докер-контейнере строку содержащую секретный ключ. Для этого, подключаемся к хранилищу через SSH (например, клиентом PuTTY). Находим файл ".ui_info". Он лежит где-то по этому пути "/var/packages/Docker/target/docker/volumes/464...../_data/id". В этом файле есть текстовая строка с секретом (сначала идёт адрес порта, потом нужный нам секрет, потом ip-адрес). Так в примере ниже, нам нужно взять строку: «05bv99x3-36f8-43e6-92c7-4b8776f2edb2».



4243,05bv99x3-36f8-43e6-92c7-4b8776f2edb2,0.0.0.0


7. На локальном компьютере ставим управляющее ПО от CrashPlan. Затем ищем там файл ".ui_info" (для Windows он лежит в папке «C:\ProgramData\CrashPlan») и редактируем его руководствуясь следующими правилами:

— На первой позиции в строке идёт порт, который в контейнере «jrcs/crashplan» поставлен в соответствие порту «4243». Так, если настройки были указаны как на шаге 4, то пишем «32774».

— Далее идет секретный ключ, который мы вытащили из контейнера на шаге 6.

— Последнее значение ip-адрес нашего хранилища, где запущен и работает клиент CrashPlan, т.е. которым мы хотим управлять. Если на Synology запущен QuickConnect, то в его настройках можно посмотреть внешний ip-адрес хранилища («Панель управления» — «Внешний доступ»).



В результате, строка в локальном файле ".ui_info" должна стать примерно такой:



32774,05bv99x3-36f8-43e6-92c7-4b8776f2edb2,192.168.1.100


8. Если всё сделано верно, то при запуске управляющего ПО от CrashPlan на локальном компьютере, он обращается по заданному ip-адресу на заданных порт хранилища (в нашем примере на 192.168.1.100 на порт 32774). Хранилище переадресует запросы на порт 4243 в контейнер «jrcs/crashplan», где бежит headless-клиент CrashPlan. Если секретный ключ совпадает, то всё ОК и подключение выполняется.



9. В приложении мы должны увидеть папку «storage» внутри которой будут созданные ранее подпапки-симлинки, а в них все наши данные. Вводим нашу лицензию, выбираем необходимые данные и начинаем их резервное копирование в облако CrashPlan. Кстати, у CrashPlan есть хорошие мобильные приложения, которые позволяют следить за этим процессом.







Полезные советы





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



2. Удобное управление файлами на хранилище. Проще всего управлять файлами на Synology через «Midnight Commander», его можно поставить на хранилище. Для этого необходимо:

— В «Центре пакетов» перейти в «Настройки» и добавить новый источник пакетов. Название: «synocommunity». Местоположение: «packages.synocommunity.com».

— Перейти в «Центре пакетов» в категорию «Сообщество», найти там «Midnight Commander» и установить его.

— Скачать и установить PuTTY.

— Включить SSH на Synology («Панель управления» — «Терминал и SNMP» — «Включить службу SSH»).

— Получить IP-адрес своего хранилища. Если на Synology запущен QuickConnect, то в его настройках можно посмотреть внешний ip-адрес — хранилища («Панель управления» — «Внешний доступ»).

— Выполнить вход на хранилище через PuTTY указав логин 'admin' и текущий пароль. Если требуются права 'root' и расширенный доступ к файловой системе (наш случай), то нужно ввести в терминале команду 'sudo -i' и повторить пароль (инструкция от Synology).

— Поскольку мы ранее установили пакет Midnight Commander, то команда 'mc' в терминале запустит его. В результате получаем доступ ко всем файлам на устройстве.



Полезные ссылки:





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282580/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

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

Понедельник, 25 Апреля 2016 г. 14:00 (ссылка)

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

Передача данных на расстояния в тысячи километров занимает несколько сотен миллисекунд, а часть пакетов просто не доходит до адресата — теряется по пути. Задержки и потери пакетов губительно сказываются на производительности транспортного протокола TCP, который обычно используется в сети Интернет. К примеру, вы находитесь в Москве и хотите создать резервную копию файла размером 3ГБ. Передача этого файла на сервер, который находится в пределах города, займет 10-15 минут. Теперь, если вы захотите восстановить этот файл, находясь вдали от дома, скажем в Китае, передача этого же файла по сети с задержкой порядка сотен миллисекунд займет уже несколько часов.







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



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

https://habrahabr.ru/post/282157/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[recovery mode] Разделение конфигурации хоста и пользователей в 3CX Phone System v14

Суббота, 24 Апреля 2016 г. 00:29 (ссылка)

В 3CX Phone System v14 в целях обеспечения отказоустойчивости и легкой миграции пользовательских АТС было сделано разделение между конфигурацией сервера (хоста и сети), на котором работает система и конфигурацией конкретной пользовательской АТС. Это позволяет решить ряд важных задач:




  • В случае системного сбоя быстро перенести конфигурацию АТС организации на другой подготовленный сервер.

  • Легкая миграция АТС организации с локального сервера в облако (на виртуальную АТС) и обратно.

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



Перенос конфигурации АТС между серверами можно сравнить с миграцией виртуальных машин между супервизорами. Конфигурация пользовательской АТС — параметры добавочных номеров, IP телефонов, правила маршрутизации и т.п., теперь не зависит от сетевого окружения сервера, на который переносится АТС. Используя автоматическое обновление DNS, можно восстановить или перенести систему практически незаметно для пользователей.



Возможны следующие типы миграции АТС организации (см. рис.)




  • С хоста А на хост B

  • C хоста B на хост А

  • С хоста А или B на 3CX Virtual PBX (в любой свободный слот)

  • С 3CX Virtual PBX на хост A или B



Рассмотрим подробнее, что включает в себя конфигурация хоста и конфигурация пользовательской АТС.

Конфигурация хоста



Конфигурация хоста содержит информацию, которую вы указали при первой установке 3CX Phone System на сервер, и некоторые параметры, указанные после инсталляции сервера в консоли управления 3CX. Параметры хоста разделяются на статические и динамические.

Статические параметры



Статические параметры хоста не могут быть изменены после установки сервера 3CX. Для их изменения необходима переустановка сервера.




  • Режим установки – Split DNS / внутренний внешний FQDN / внутренний IP

  • Используемый веб сервер (IIS или Abyss)

  • Порты веб сервера

  • FQDN имя

  • Самоподписанный SSL сертификат безопасности



Динамические параметры



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




  • Внешний IP адрес

  • SIP и RTP порты

  • Порт и пароль 3CX туннеля

  • Параметры почтового сервера

  • E-mail адрес администратора



Конфигурация пользовательской АТС



Конфигурация пользовательской АТС содержит все параметры конкретной системы 3CX, включая имя пользователя и пароль администратора. Поэтому учетные данные администратора АТС также переносятся на другой хост. В конфигурацию входят:




  • Пользователи (добавочные номера)

  • Группы и права пользователей

  • Данные об IP телефонах и параметры автонастройки

  • Системные добавочные номера – очереди и группы вызовов, голосовые меню и голосовая почта

  • Общие параметры системы (раздел АТС интерфейса)

  • Адресные книги

  • Конфигурация SIP транков и ТфОП шлюзов

  • Настройки входящих и исходящих правил

  • Имя пользователя и пароль администратора АТС



Пример переноса конфигурации



Как было сказано, при переносе конфигурации АТС на новый сервер конфигурация хоста не переносится. Поэтому, если вам необходимо перенести АТС на хост, использующий SIP порт 6060, действуйте следующим образом:




  • Установите АТС и пройдите мастер первоначальной настройки

  • Войдите в консоль управления и в разделе Параметры – Сеть – Порты укажите новый SIP порт

  • Восстановите резервную копию системы, в соответствии с документацией



Дополнительная информация







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282287/

Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Длительное архивное хранение данных, или Как посмотреть селфи моей прабабушки?

Среда, 21 Апреля 2016 г. 00:38 (ссылка)

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



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



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



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



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



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



1. Физическая сохранность носителей и удельная стоимость хранения.



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



– Оптические диски (CD, DVD, BD и т.п. диски) и флеш-накопители. Принято считать, что данные на таких носителях могут разрушаться через несколько лет, и, во всяком случае, через 25 лет её, скорее всего, вряд ли удастся прочитать.



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



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



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



2. Техническая совместимость носителей.



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



Итак, 30 лет назад шёл 1986 год. В зависимости от своих технических предпочтений, пользователь того времени мог бы счесть наиболее заслуживающим доверия носителем для сохранения данных: 9-дорожечную магнитную ленту большого компьютера; широко используемые на персоналках 5- или 8- дюймовые дискеты; или новейшую по тем временам 800-килобайтную 3-дюймовую дискету для дисковода фирмы Sony от компьютера Macintosh (несовместимую с более поздними 3-дюймовыми дисководами на 1.44 мегабайта). Даже предположив идеальную физическую сохранность носителей, чтение в наше время с любого из них, конечно, возможно, но обойдётся в значительные затраты времени и денег, с которыми вряд ли кто станет связываться ради маминого селфи. Ещё через 30 лет технологии чтения этих носителей, вероятно, будут окончательно утрачены.



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



В качестве долговременного архивного носителя информации в настоящее время чётко позиционируются магнитные ленты стандарта LTO. Мир LTO устроен таким образом, что каждые 2-3 года выпускается новое поколение стандарта, отличающееся примерно удвоенной ёмкостью, и выпускается оборудование под это поколение (сейчас действующим стандартом является LTO-7). Однако, стандарт LTO регламентирует (а общепринятая практика производителей обеспечивает) совместимость стримеров LTO с носителями для чтения только на два поколения назад, а для записи – на одно поколение. Это значит, что современный стример LTO-7 способен читать только кассеты LTO-7, LTO-6 или LTO-5, а современная кассета LTO-7, будучи записана сегодня, окажется несовместимой со стримерами LTO-10, появление которых можно прогнозировать примерно на 2022 год, и уже через 10 лет (в 2026 году) не будет читаться ни одним имеющимся на рынке устройством.



Допустим, мы встанем на сторону дисковиков и запишем информацию на современный жёсткий диск SATA или SAS. Этим стандартам интерфейса и так уже более 10 лет, и крайне маловероятно, что они продержатся ещё хотя бы 10. То же самое относится к USB в современном виде. Отсутствие фактической почвы делает все рассуждения об отдалённом будущем физических интерфейсов крайне спекулятивными, но можно предположить, например, что через 10-20 лет интерфейсы дисковых устройств вполне могут стать оптическими, и в таком случае будут несовместимы с современными устройствами уже на уровне среды передачи данных.



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



Хранение данных в сетевом архиве позволяет переложить указанные проблемы на специально обученных людей, но остаётся имеющим указанные в предыдущем разделе риски. Уместно напомнить, что большинство лидеров компьютерного рынка 30-летней давности к настоящему времени ликвидировалось, за несколькими исключениями вроде IBM, Apple и Microsoft, которые, однако, с тех пор очень значительно поменяли сферу деятельности.



3. Совместимость форматов данных.



Об этом вопросе пишут совсем редко.



Так как 30 лет назад всё-таки на самом деле не было цифровых селфи, то давайте представим, что нам из 1986 года попал простой текстовый электронный документ, и что нам удалось удалось решить все технические проблемы и его записать в файл современного компьютера.



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



– от пользователя мейнфрейма 1986 года нам на диск может попасть образ виртуальной колоды перфокарт с фиксированными 80-символьными записями в кодировке EBCDIC (ДКОИ);



– от пользователя Macintosh мы получим документ ClarisWorks;



– от пользователя PC мы получим, например, документ досовского текстового редактора ChiWriter или WordPerfect, хотя при удаче это может оказаться и обычный текстовый файл;



– и только с пользователем Unix нам практически точно повезёт, и мы, вероятно, получим от него обычный читаемый текстовый файл (в кодировке русского языка koi8-r или ещё похуже).



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



На чём же базируется наша неявная уверенность, что мы сможем, вырвавшись на полчасика из обьятий Альцгеймера, показывать своим скучающим внукам невнятные фотки из отпуска 2016 года? Допустим, при известном оптимизме можно представить, что формат jpeg, ввиду его огромной распространённости в современной жизни, можно будет как-то отконвертировать в форматы изображений, которые будут приняты в светлом альцгеймеровом будущем (хотя исторических прецедентов такого длительного срока жизни формата не было). Но уж точно это не будет относиться ни к raw-форматам фотокамер, ни к форматам офисных документов вроде doc/docx, ни к электронным книгам fb2/epub и т.д., просто из-за того, что нет субъекта, имеющего цель и возможность обепечить неограниченную совместимость такого формата.



4. Что же делать?



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



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



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



А селфи для правнуков лучше всё-таки на всякий случай напечатать на фотобумаге.



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/282085/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Dmitriykn

Как начать работать с сайтом еще до изменения записей в DNS

Суббота, 10 Апреля 2016 г. 00:28 (ссылка)

Это цитата сообщения KtoNaNovenkogo Оригинальное сообщение

Что нужно изменить в настройках WordPress при бэкапе и переносе на другой хостинг

http://ktonanovenkogo.ru/vokrug-da-okolo/hosting/rezervnoe-kopirovanie-dannyx-vashego-sajta-i-perenos-sajta-na-drugoj-xosting-s-pomoshhyu-filezilla-i-phpmyadmin.html

Как сделать бэкап и восстановиться из резервной копии, а так же нюансы переноса сайта (Joomla, WordPress) на новый хостинг | KtoNaNovenkogo.ru - создание, продвижение и заработок на сайте

Бэкап и перенос сайта

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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
KtoNaNovenkogo

Что нужно изменить в настройках WordPress при бэкапе и переносе на другой хостинг

Суббота, 10 Апреля 2016 г. 00:25 (ссылка)
ktonanovenkogo.ru/vokrug-da...admin.html

Как сделать бэкап и восстановиться из резервной копии, а так же нюансы переноса сайта (Joomla, WordPress) на новый хостинг | KtoNaNovenkogo.ru - создание, продвижение и заработок на сайте

Бэкап и перенос сайта

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

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Veeam Endpoint Backup FREE 1.5: новые возможности

Среда, 06 Апреля 2016 г. 13:19 (ссылка)

Казалось бы, совсем недавно мы публиковали серию постов о бесплатном продукте Veeam Endpoint Backup FREE 1.0 для бэкапа физических машин, а вот уже вышла и новая версия — Veeam Endpoint Backup FREE 1.5. Но прежде чем начать рассказ о ее фичах, хочется поблагодарить наших пользователей, которые не просто с энтузиазмом приняли новый продукт Veeam, но и активно делились своим опытом и «фишками» его использования, давали отзывы, комментарии и идеи для развития. Версия 1.5 вышла в том числе и благодаря вам, уважаемые читатели, поэтому спасибо, что выбираете Veeam и не ленитесь давать фидбэк.

Итак, какие новинки ожидают вас в Veeam Endpoint Backup FREE 1.5?

Добро пожаловать под кат!









Оповещения по электронной почте



Наверное, это была самая часто запрашиваемая фича с момента выхода первой версии Veeam Endpoint Backup FREE — и вот она в полном вашем распоряжении. Для того, чтобы получать email-уведомления о том, как прошел бэкап, идем в настройки, вводим адрес получателя (если почтовый сервер требует аутентификации – то еще и пароль) и затем выбираем, о каких результатах хотим получать сообщения: успешное завершение задания (Success), завершение с предупреждением о возможных недочетах (Warning), завершение с ошибкой (Error). Можно указать, что должна содержать тема письма – по умолчанию в ней будет результат работы задания, имя забэкапленной (или не забэкапленной) машины и время завершения.

В секции SMTP server settings вводим настройки почтового соединения:

— имя сервера и порт

— имя пользователя почтового ящика

— если хотим использовать безопасное соединение (Use secure connection), то ставим соответствующую галочку.

Затем для проверки настроек нажимаем Test Message, чтобы отправить тестовое сообщение.







Новые настройки для расписания



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







Защита от CryptoLocker



О том, что это за гадость и чем она грозит пользовательским данным, рассказывалось в англоязычном блоге Veeam: https://www.veeam.com/blog/how-to-avoid-losing-data-veeam-endpoint-backup-vs-cryptolocker.html. Там же рассматривались и способы предупреждения этой напасти. После отработки CryptoLocker-а единственным методом реанимации машины будет-таки восстановление из резервной копии. Но тут возникает вопрос: как предотвратить шифрование CryptoLocker-ом файлов самого бэкапа?

Если вы используете в качестве хранилища резервных копий папку общего доступа или репозиторий Veeam Backup & Replication, то можно ограничить список учетных записей, у которых есть доступ к нему, и завести учетки специально для резервного копирования. Однако многие используют для хранения бэкапов USB-устройства — как быть в этом случае? Veeam Endpoint Backup FREE 1.5 предлагает новую опцию: автоматическое отсоединение съемного устройства после завершения резервного копирования (Eject removable storage once backup is completed):







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





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











Полезно: Эта опция поддерживается и для создания отдельного полного бэкапа с помощью командной строки.



И еще кое-что…



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

— в панели задач теперь отображается прогресс задания резервного копирования

— в панели управления Veeam Endpoint Backup Control Panel можно переключать представление бэкапов в виде блоков на диаграмме (по правому клику), показывая время создания или размер:







— при загрузке с носителя Veeam Recovery Media отображается сигнал беспроводного подключения (Wi-Fi)

— перераспределение дискового пространства при восстановлении тома (volume resize) теперь можно задавать не только в мегабайтах (что было довольно неудобно, если том с терабайт), а выбрать нужную единицу измерения, например, гигабайт, и указать желаемый размер (подробнее см. здесь: https://helpcenter.veeam.com/endpoint/15/volume_restore_resize.html)

Есть нововведения и в осуществлении технической поддержки:

— во-первых, в диалоге Report an issue теперь вам нужно будет дать свое согласие на автоматический сбор и отправку журналов на сторону Veeam;

— во-вторых, прежде чем будет создана заявка на портале техподдержки, Veeam Endpoint Backup FREE проверит, не пора ли вам обновить версию продукта.

В новой версии мы также позаботились и о том, чтобы продлить срок службы батарей ноутбука или планшета. Помимо уже реализованной логики, согласно которой запуск задания бэкапа откладывался, если заряд батареи был меньше 20%, теперь Veeam Endpoint Backup FREE умеет определять, подключен ли ваш ноутбук к зарядному устройству, если не подключен – то может отложить запуск задания, сэкономив ресурс батарейки.

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



Вместо заключения — полезные ссылки







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/281050/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Легенда о международном авось

Четверг, 31 Марта 2016 г. 16:02 (ссылка)

Признанный мастер бэкапа — ящерица. Отбросив свой хвост при форс-мажорных обстоятельствах, вскоре она отращивает новый. Это эволюционно заложено природой и не требует от земноводного особых усилий. Отдельные явления восстановления органов или клеток встречаются и у других животных, в том числе у homo sapiens. Однако сегодня ситуация поменялась и у человека, в отличие от ящерицы, появилась ещё одна значимая ценность — информация, а именно данные, которые он бережно собрал, накопил, и… А вот что происходит с ними дальше, зависит от того, насколько homo соответствует званию sapiens. Как вы уже догадались, соответствуют не все. Не даром же придуман World Backup Day, который празднуется как раз сегодня.



Итоги конкурса внутри!



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



Что имеем — не храним, потерявши — плачем



Мы всегда тщательно готовимся к World Backup Day. Например, в прошлом году мы провели глобальный опрос, согласно которому свыше 75% потребителей хранят свои персональные данные в цифровом формате. Больше половины респондентов утверждают, что их данные ценнее, чем сами устройства-носители, и осознают необходимость их защищать. Результаты опроса также говорят о том, что потребители, лишившись своих личных фотографий, будут почти в три раза сильнее расстроены, чем при потере телефона, компьютера или планшета.



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



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



Несмотря на сравнительную беспечность, почти 50% респондентов оценивают свои данные достаточно высоко: 50 тысяч рублей и более. Только 5% опрошенных готовы в действительности потратить эту сумму на восстановление данных в случае их потери, однако 94% заявили, что согласны единовременно заплатить 3-4 тысячи рублей за превентивную защиту данных и создание их резервной копии.



А вот ещё несколько не менее занимательных фактов:




  • Согласно исследованию National Archives & Records Administration in Washington 93% компаний, которые потеряли свои данные на срок 10 дней или более, подали на банкротство в течение одного года после катастрофы и 50% подали на банкротство практически сразу.




  • Исследование Richmond House Group показало, 20% малого и среднего бизнеса терпят практически катастрофу из-за потери важных данных каждые пять лет.




  • По оценкам Gartner, в 2015 году 40% малого и среднего бизнеса, которые используют сеть Интернет более, чем для проверки почты, были открыты к доступу хакеров, причём более, чем 50% из них даже не догадывались о произошедших атаках.



Как уходят данные?



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




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





    — Мой компьютер вышел из строя! Жёсткий диск повреждён! Что мне делать?!

    — У вас есть резервная копия?

    — Что, у меня? Он что, сейчас взорвётся?!





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





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




  • Форс-мажор случается и, что самое страшное, его нельзя избежать. Потоп, пожар, замыкание проводки, попадание молнии и иные природные и техногенные катастрофы могут привести к безвозвратной потере данных вместе с физическими носителями. Если такая версия вам кажется неправдоподобной, что можно прислушаться к @@Win32Sector, который рассказал как раз о подобном случае:
    Жили-были, не тужили 6 железных серверов в маленькой уютной серверной. Только о бекапах никто не думал. Бэкапы, да кому они нужны, не ссы, ничего не потеряется, говорил мне генеральный директор, отклоняя очередную служебку о необходимости закупки СХД под бекапы. А через 2 месяца после крайней служебной записки, раздался звонок в 4 часа утра в воскресенье от дежурного охранника: «У вас там чё-то в здании дымит». Сон сняло как рукой, холодный липкий пот, сжавшийся задний проход — все как в классике. Через час я на месте, и наблюдаю выгоревшее здание, где в том числе была серверная. Всё, что нажито непосильным трудом: два магнитофона, три портсигара… Но, зато, теперь всё как надо. Серверная просторная, бекапы на СХД, бекапы на ленточки, удаленная СХД — всё как у людей.

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




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




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




  • Кража данных, хоть и стоит в этом списке на последнем месте, его как-раз таки не занимает. Данные могут быть похищены умышленно или случайно вместе с носителем (флешкой, фотоаппаратом, ноутбуком). И именно в этом случае восстановить их сложнее всего. Между прочим, каждые 53 секунды крадётся 1 ноутбук.



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



Основы резервного копирования



Существует несколько методов резервного копирования...



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



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





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

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



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



Дедупликация данных — ещё одна технология, применяемая при резервном копировании. Он заключается в уменьшении объёма, занимаемого хранимыми данными, путём выявления повторяющихся идентичных данных и сохранения их только один раз. Благодаря дедупликации также можно снизить загруженность сети: если во время резервного копирования обнаружится, что блок данных является дубликатом уже сохранённых, его содержимое не передается по сети. Можно долго рассказывать про поиски и замены ссылок дубликатов на ссылку уникального вхождения, но у Acronis есть крутой кейс и мы лучше проиллюстрируем дедупликацию им.



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



Тут-то Acronis и использовал дедупликацию — объём избыточных данных компании сократился на 300-500 ГБ ежедневно. Хранение и управление файлами стало значительно эффективнее.



… несколько мест резервного копирования...



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



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



Network Attached Storage (NAS) обеспечивает удобный доступ из любого места в сети. Фактически отдельный компьютер (группа компьютеров) с данными. Такое решение легко управляется и администрируется.



Конечно, для надёжной защиты корпоративных данных места хранения резервных копий лучше комбинировать по универсальному правилу. Acronis рекомендует:







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



А что делать частным лицам? Да, собственно, то же самое — хранить данные распределённо:




  • пользоваться облачными хранилищами, синхронизировать с ними важные файлы;

  • использовать внешние жёсткие диски (не ронять и не сотрясать их сильно) и ёмкие флешки надёжных производителей;

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

  • использовать встроенные возможности операционной системы.



Тут тоже есть своё универсальное правило:





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



Итоги конкурса и предыдущего поста



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



Как и обещали, объявляем результаты конкурса. Одна история душетрепательней другой :)



1 место занял пользователь Pocket_virys, приз — Bluetooth-колонка:





Его история:
Я вот раньше бекапы не делал… Считал для себя лишней вещью. Файлов было накоплено в электронном виде не так много. С определённого периода я стал делать бекап телефона, а тогда еще у меня был Win Mob. 2003, т.к. восстанавливать его после очередного Hard reseta было длительно. Мой ноут по прежнему оставался без бекапа, да и зачем? есть же C и D думал я, если что не так проще переустановить систему, чтобы исключить полностью проблему, а файлы мои сохранятся на D диске. Эх молодость… Теперь я делаю бекапы регулярно, а все потому-что одна «дама» с которой я имел длительные отношения, при расставании в порыве гнева и обиды, с целью отомстить пнула ножом мой ноутбук!!! Удар пришелся как раз в район расположения моего тогда еще 320гб ЖД. Насколько сильны женщины могут быть в порыве гнева! Нож вошел как в масло повредил корпус. Достал и до ЖД. Так я потерял не просто работоспособность своего ноутбука, но и все самые важные фотографии с моего школьного выпускного и поездки в Ялту, а так же отдыха в Геленджике. Собрать по крупицам с других мест удалось не многое. Теперь же, точки восстановления, архивирование, облачные копии и прочее я делаю хоть и не регулярно, но с некоторым постоянством.


2 место заняла пользователь Llammt, ей достаётся портативная зарядка:





Её история:
Это случилось со мной в первый месяц первой работы, когда я была наивной выпускницей с девственно-чистым резюме. По-моему, никогда ни До, ни После я не производила за раз столько кирпичей… Дело было в одном НИИ, надо было программно обработать результаты экспериментов. Для этой цели мне выделили единственный на все учреждение сильный компьютер.Жесткий диск на нем оказался забит под завязку — почти терабайт презентаций, таблиц, докладов, видеозаписей конференций и прочей заумности. Спрашиваю у заведующего лабораторией, куда все это девать. Завлаб авторитетно отвечает — никто на этом компе давно уже не работает, таблицы никому не нужны, если нужно свободное место на диске, то удаляй все к чертовой бабушке. Сношу винду, ставлю линукс, начинаю работать. Проходит неделя, вторая… С утра зовет меня к себе заведующий. Тут, — говорит, — такое дело. Искали архивы, связались с нашим бывшим системным администратором, и он вроде как припоминает… (тяжелая пауза) что по просьбе бывшей заместительницы директрисы скинул все на компьютер в 28-й.



А в 28-й комнате только один компьютер — мой, рабочий. И вот этот терабайт презентаций с таблицами, вместе с виндой отправившийся в цифровой рай полмесяца назад, как выясняется, кроме всего прочего, включал в себя электронную хронику всего НИИ за последние *нцать лет!

Меня даже никто не обвинял (сами не знали, кто у них куда скинул архив), но было все равно страшно грустно. А все-таки закончилось хэппи-эндом. Hiren's CD одной из ранних версий (какая-то некромантская утилита в его составе, уже не помню названия) вернул к не-жизни снесенную винду, и над этим зомби я колдовала еще сутки. В итоге, воскресло около трех четвертей важной информации, правда, в виде нумерованных архивов — но их уже сортировали несчастные студенты-практиканты. Когда архив был, наконец, восстановлен, с него впервые в истории НИИ была снята копия.


И 3 место и приз Bluetooth-монопод достаётся пользователю Dum_spiro_spero:





Его история:
Вот еще тру стори. Работал я в студенческое время в далеких 90-х эникейщиком… нет, сисадмином в некой торговой конторе. И была там бухгалтерская программа которая регулярно обновлялась. Чтобы сделать обновление по всем правилам надо было сделать бэкап, обновиться, развернуться из бэкапа. Я делаю все как надо,, и… забэкапленные БД не хотят разворачиваться. И даже круче — попытка разархивирования БД приводит к синему экрану. В общем в конторе я провел всю ночь, в 9 утра пришла глабухша — и я ей выдал — вы только не волнуйтесь — но ваша база -…… с главбухшей чуть не случился сердечный приступ. Утром по пути в институт встречаю друга — рассказываю о событии — он: «А, это та контора где ты РАБОТАЛ?», я: «Да, боюсь, что так». К счастью нашлись дискеты с базой двухмесячной давности, и дальше вся контора две недели все перебивала. А вот более печальная история. В наш научный институт залезли воры, вскрыли шестнадцать дверей и похитили ноуты. А вахта… то ли спала, то ли испугалась. Потом поставили видеонаблюдение. Через месяц эта же воровская компания (из рядом живущего жителя и ЛКН) решила, что надо повторить вылазку на склад бесплатных ноутбуков и была благополучно задержана. Но ноут с недописанной диссертацией шефа так и канул в лету.


Просим победителей связаться с нами через личные сообщения.



А пока идём создавать бэкапы и произносить клятву World Backup Day. Постулат о том, что не горят рукописи, с лёгкостью опроверг Гоголь. Факт того, что данные имеют свойство исчезать в самый неподходящий момент, подтверждает цифровая действительность XXI века. Так что пока не решили, что «а пропади оно всё пропадом, ухожу жить в лес», позаботьтесь о том, чтобы рядом с вами были лучшие друзья, приятные воспоминания и тщательно сохранённые данные.



С международным днём резервного копирования!



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/280604/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Облачные хранилища для тематических данных

Пятница, 18 Марта 2016 г. 15:46 (ссылка)

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

И набухнув дождем, друг на друга они набегают и давят друг друга.

И взрываются с треском они, как пузырь…

Аристофан, комедия «Облака»








Пару лет назад в статье о бэкапе персонального фотоархива я уже писал о возможности активного использования облачных сервисов для хранения персональных данных определённого типа (там речь шла о фото). С тех пор облачные технологии получили дальнейшее развитие, гигабайт подешевел, а доллар подорожал; мы же как пользовались Google Drive или Dropbox, так и продолжаем пользоваться ими. Во всяком случае, если раньше идея засунуть пару терабайт фотографий в облако приходила в голову главным образом коммерческим фотографам (видеооператорам, музыкантам), то сейчас подобное решение становится скорее нормой, чем исключением из правил. А стоимость хранения… что ж, почти за всё надо платить! Тем более, что и бесплатных облачных сервисов (или хотя бы таких, которые дают хороший объём хранилища в качестве бесплатного старта) в наше время пруд пруди. (Лично мне Яндекс за какие-то неясные заслуги подарил на облаке Яндекс.Диск аж 210 бесплатных гигабайт, и это в 210 раз больше, чем объём винчестера на моей самой первой рабочей станции!)



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



Доступ к облачным хранилищам



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




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

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

  • Третий способ – синхронизируемая локальная папка на компьютере.



У всех трёх способов есть свои преимущества и недостатки.



Одно облако, одна утилита, один интерфейс


Первый из методов хорош, например, если облако, в котором предполагается осуществлять хранение данных, тесно связано с функциональностью приложения. Так, моя любимая программа резервного копирования Handy Backup предлагает сервис облачного хранения бэкапов HBdrive, к сожалению, платный. Google Picasa тесно интегрирована с облаком Google Drive в рамках сервиса Google+, что можно рассматривать как комбинацию всех трёх стандартных подходов. По тому же принципу работают и многие фотохостинги, например, неоднократно обруганный всеми за испорченные снимки сервис хранения фотографий «ВКонтакте». Печально, но попадаются иногда и монстры, требующие установки специального клиента даже для самой обычной функции – загрузки и выгрузки хранимых данных в облако. Не путайте эти программы-клиенты с демонами или утилитами синхронизации, прилагающимися к третьему способу. В наш век едва ли кто-то будет ставить специальный клиент просто для того, чтобы копировать файлы туда-сюда; большинство сервисов предлагает более простые методы.



Интересно, что к первому способу относятся во многих случаях и облачные сервисы, интегрированные с операционными системами, такие, как OneDrive или Ubuntu One, ныне, насколько мне известно, давно почивший в бозе. При переходе с системы на систему эти облака-приложения могут вызвать у вас некоторую головную боль. Самые порядочные разработчики здесь, на мой вкус, это авторы iCloud – у меня ни разу не возникло проблем с доступом к этому облаку из других систем. А вот холивар между Google/Android и Windows Mobile привёл к тому обидному результату, что в высшей степени полезное и насыщенное информацией облако Google Drive у меня не работает корректно с очень хорошим телефоном Microsoft Lumia 640XL. Воистину, паны дерутся, а у холопов чубы трещат, и от священных войн между корпорациями (в которых, естественно, с готовностью принимают участие толпы «технически подкованных» леммингов с обеих сторон) страдают обычные пользователи, желающие просто получить хороший результат при минимуме геморроя.



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

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



Веб-доступ и веб-клиенты


Пожалуй, самый распространённый способ работы с облачными сервисами. Хорош уже тем, что обеспечивает почти полную независимость от платформы (был бы для браузера соответствующий плагин!). Грузите данные взад-вперёд, сколько влезет! Более того, хороший сервис такого рода непременно предложит вам дополнительные возможности для доступа к данным через веб-интерфейс. Так. В Яндекс.Диске вы можете редактировать ваши документы в онлайн-версии Microsoft Office, в iCloud – пользоваться фирменными эппловскими офисными редакторами Pages, Numbers и Keynote. Функции онлайн-редактирования фотоснимков в облачных сервисах тоже хорошо известны, хотя, мягко говоря, уступают в возможностях Photoshop и даже GIMP. Словом, через браузер вы можете получить не только инструментарий загрузки и выгрузки данных, но и отличный набор базовых утилит, обеспечивающих вам срочные и необходимые исправления.



Минусы? Смотря с какой стороны разглядывать. Веб-интерфейс, грубо говоря, работает с облаком, а не с вашими данными; с данными в этом случае работаете вы сами. Если вам нужно, например, обработать фотоснимок в локальном редакторе, вы должны загрузить его в нужный каталог, обработать локально и затем загрузить обратно на облако. Звучит нестрашно? А представьте себе, что таких фотоснимков триста штук подряд? Можно, конечно, выгрузить их все разом, особенно если вы пользовались какой-нибудь идеей структуризации каталога. А если они разрозненные? Количество мелких лишних операций в этом случае прогрессирует линейно; к тому же возрастает риск человеческой ошибки (загрузили, поменяли, а выгрузить забыли. Или, того хуже, всё отредактировали, устали и по ошибке выгрузили назад исходники). А оно вам надо?



Синхронизированная локальная папка


Да-да, это сейчас умеют многие. Когда этому научится Google Drive под Linux, наступит счастье и мир народам. А пока довольствуемся тем, что есть. Ставим утилиту синхронизации в автозапуск, настраиваем соединение с облаком, создаётся локальная папка – вуаля! Никакой магии, все ваши данные просто находятся одновременно и там, и тут! Хотите, открывайте их локальными приложениями, хотите, пользуйтесь облачным интерфейсом, задавайте параметры синхронизации, открывайте доступ по ссылке или по имени пользователя – всё, что угодно, всё в ваших руках! Утилита синхронизации сама учтёт в облачном хранилище все сделанные вами локально изменения.



И изменения, сделанные вашими кривыми руками (или продиктованные усталым невнимательным мозгом) – конечно же, тоже будут учтены. И результаты ошибочного удаления (не через корзину, ибо вы уже давно открыли для себя волшебную силу Shift+Del) – естественно, будут отражены тоже.



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



Естественно, что всё это скорее придирки. Абсолютно незачем разводить в наш век цифрового просвещения вирусохранилище на своём ПК! И регулярный бэкап ваших цифровых данных тоже никто не отменял. Но факт есть факт; любой сервис, синхронизирующий локальную папку и облачный аккаунт, подвержен обоим видам опасностей – и тем, что поражают локальные данные, и тем, что угрожают сети. Ни в коем случае не сочтите это призывом к отказу от использования синхронизированных хранилищ; я сам пользуюсь и Яндекс.Диском, и Google Drive, и Dropbox без тени сомнения. Просто помните: осторожность, осторожность и ещё раз осторожность! Не работайте из-под аккаунта администратора (да-да, и в Windows обязательно создайте пользователя без административных привилегий), включите файрволл, не ставьте на компьютер что попало, делайте регулярный бэкап и проверку на вирусы… ну, да мне ли учить вас элементарным правилам?! Тогда всё будет ОК.



Функционал облачных хранилищ



Хорошо, если облако связано со специализированным приложением; весь набор функций, как говорится, налицо. В случае с фотографиями хороший пример – Google Picasa; всем отличный сервис, и каталогизатор, и хранилище, и альбомы создаёт – одна беда: не хочет работать с RAW-файлами! Куда хуже, если перед началом использования сервиса приходится разбираться со специфическими ухищрениями маркетологов; мега-популярный облачный фотохостинг Loom, например, обещает безграничное пространство для хранения фотографий, но на деле предоставляет всего лишь 250 Гб за существенные (для среднего любителя) $9.99 в месяц. Оно того стоит? Сложный вопрос, каждому своё, как говорится. Назойливая реклама на «Радикале», бывшие квадратные форматы снимков Инстаграм (сейчас, говорят, отменили это ограничение, фанаты квадратиков плачут кровавыми слезьми), кривой рендеринг снимков «ВКонтакте» — что-нибудь да вылезет обязательно. Проверяйте внимательно всё, что умеет выбранное вами хранилище на самом деле, в том числе и по отзывам пользователей!



Особенно тщательно я рекомендовал бы подходить к выбору малоизвестных облачных хранилищ, предлагающих интересные и вкусные вещи за сущие копейки. Внимательно читайте те пункты, которые приписываются в рекламах и соглашениях пресловутым мелким шрифтом! Например, с вас могут потребовать денежки не только за хранение, но и за право восстановления ваших данных; в некоторых случаях это оправдано, если речь идёт о настоящем «спецхране», но чаще это просто отражает завышенные аппетиты владельцев сервиса. Если вам предлагают «размещение рекламы» вместе с вашими разделяемыми данными или, например, теми же фотоснимками – проверьте, как это выглядит! Вашим сослуживцам вряд ли захочется выкачивать ваш проект «медленно и бесплатно, со скоростью 56 КБ/сек, после просмотра трёхминутного порноролика», либо же «быстро и без рекламы, всего за $20» (порноролик всё равно прилагается во всплывающем окне). Не будем показывать пальцем на эти хостинги и сервисы; все хотят кушать, и их администрация в том числе. Но нам ведь чужих проблем не надо, правда?



Есть и ещё одна проблема функциональности; в списке возможностей вы её не найдёте (или найдёте голословные утверждения вроде «лучшее», «надёжнейшее» и т.п.), зато найдёте наверняка во многочисленных, обычно гневных, отзывах о том или ином хранилище. Это – проблема реализации внутренних алгоритмов хранения, отвечающих за надёжность сервиса, быстроту загрузки и выгрузки, характер представления данных и так далее. В частности, будьте готовы к тому, что авторитетные эксперты обязательно назовут любой ваш сервис хранения фотографий «фотопомойкой» (если, конечно, они сами не пользуются им же): там «фотки» безбожно жмут, там криво рендерят, там уменьшают до неприемлемых размеров (вы же, надеюсь, знаете, что Настоящий Фотохудожник сразу же печатает все свои картины на холсте или на барите, минимум метр двадцать по короткой стороне?), там – искажают цвета, врубают какой-нибудь бестактный «улучшайзинг», и в половине случаев – бессовестно воруют контент! Ну и, конечно же, на этом вашем хостинге ни один уважающий себя «профи» или «продвинутый любитель» ничего хранить не будет, а тусуется там завсегда самое безграмотное и лишённое всяческого вкуса фотобыдло. Впрочем, последняя претензия имеет уже мало отношения к собственно хостингу, зато все остальные могут внезапно оказаться и объективными. Прежде чем сливать на хостинг гигабайты (и доллары!), попробуйте, каково качество хранения ваших данных на этом облаке? Устраивает ли оно вас, ваших коллег, семью, клиентов? Если да – смело пишите все вышеперечисленные претензии в раздел чужой вкусовщины. Если же нет… Словом, будьте предельно внимательны и осторожны, как говорят в метро при посадке.



Организация – ключ к успеху!



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



Облачное хранилище должно быть встроено в ваш рабочий процесс. У меня, например, это выглядит так: облако – Handy Backup – RAWtherapee – GIMP или Photoshop – каталогизатор (Picasa, iPhoto) или снова Handy Backup – снова облако. У Handy Backup есть приятная особенность, эта прога по умолчанию копирует всё в исходных форматах, поэтому «бэкап», полученный с её помощью, по сути представляет собой результат прямого копирования, сразу же доступный для обработки в фоторедакторах. Как следствие, обычно именно её я и использую для загрузки и выгрузки данных на облака всех перечисленных видов. (Впрочем, сам я реально пользуюсь только четырьмя облачными сервисами – Dropbox, чтобы поделиться превью или результатами с заказчиком, Google Drive или Яндекс.Диск для хранения творческих проектов и сопровождающих документов, а также HBdrive для, собственно, бэкапа как такового. OneDrive и iCloud у меня сейчас используются исключительно для приватных нужд). Естественно, ваш рабочий процесс (workflow) может выглядеть как-то по-другому, да и сервисы могут разниться; для музыкантов есть, например, Noteflight. Но общий смысл задачи неизменный; облако должно быть не просто «супер-пупер функции, много бесплатных гигабайт!», а обязано полностью (или ближе всего среди конкурентов) подходить под ваш конкретный набор требований. Сделайте это, и вы не ошибётесь! В том числе, вы освободите свой разум от нытья советчиков, рекомендующих вам «больше никогда-никогда не иметь дело с этой помойкой», потому что там у них, видите ли, «вечно цвета задраны и скинтона в циан уходят». А может, вам так и надо – чтобы скинтона, да сразу и в циан?!



Хорошей альтернативой всем вышеперечисленным решениям являются приватные облака. Такой сервис предоставляют как провайдеры Интернет-услуг, так и, например, производители NAS. Оговорюсь сразу, что задача поднять и администрировать частное облако, видимое и успешно используемое через Интернет, не относится к лёгким и простым. Во всяком случае, мне, человеку, не первый десяток лет горбящемуся за компьютером, это не удалось ни разу из тех двух попыток, на которые мне не жалко было потратить своё время. Но технологии отнюдь не стоят на месте, и пресловутый подход «воткнул и играйся» вот-вот дойдёт до частных облаков в полной мере. Проследите лишь, чтобы ваш приватный облачный сервис поддерживал доступ к данным через браузер. Иначе вы обязательно окажетесь в самый ответственный момент где-нибудь в Катманду, в Баб-эль-Мандебском проливе или даже на Гваделупе, с чужим компьютером, на котором, естественно, не стоят и не могут быть поставлены никакие обслуживающие утилиты для вашего личного облачка, и с острой необходимостью немедленно достучаться до содержимого хранилища, а иначе уже точно будет что-то нехорошее…



Ну, а в заключение позвольте дать вам ещё один совет, основанный на личном опыте. Какой бы шикарный облачный сервис вы себе ни нашли – хотя бы раз в неделю сливайте все ваши данные в виде бэкапа на локальный носитель, так или иначе находящийся физически в вашем полном личном распоряжении – например, на USB-устройство или на подключенный к локальной сети накопитель NAS. Иначе вы рискуете нажить самые неожиданные проблемы, хотя бы из-за такой мелочи, как временная потеря доступа к Интернету. Поверьте, что даже среди бесчисленных облаков ваши личные данные всегда заслуживают хотя бы клочка чистого неба. Удачи вам в поиске подходящих хранилищ!







Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/279615/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Использование PowerShell для работы с Veeam Backup Free Edition

Вторник, 01 Марта 2016 г. 12:30 (ссылка)

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



День добрый,

Меня зовут Владимир Ерёмин, я работаю в компании Veeam Software на позиции product manager. Одной из вверенных мне областей является PowerShell оснастка к нашему продукту Veeam Backup and Replication, и именно о работе с оной и пойдет речь далее.









Начнем с небольшого лирического отступления.

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

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



Бесплатно не значит плохо



Как и у каждой уважающей себя софтверной компании, у нас есть свой флагманский продукт, в нашем случае — всем известный и горячо любимый Veeam Backup & Replication. Чтобы никто не ушел обиженным, выпускается он в нескольких версиях, начиная от Free и заканчивая Enterprise Plus.

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

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

Все поменялось, когда с выпуском Veeam Backup & Replication v8 Update 2 мы отдали на откуп общественности несколько PowerShell командлетов. Используя их, пользователь был в состоянии написать простой скрипт, с помощью которого создавался бэкап одной или нескольких машин. Помимо этого, благодаря Task Scheduler, скрипту можно было выставить какое угодно расписание.

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



От слов к делу. Параметры



Как было сказано ранее, скрипт позволяет создавать бэкапы выбранных виртуальных машин. Машины могут находиться как на обычных хостах/кластерах, так и тех, что управляются vCenter’ом (да, в качестве разбора был выбран пример для VMware).

У скрипта есть три обязательных параметра: имена виртуалок, хосты/кластеры/vCenter, на которых они восседают, и папку, в которую положатся бэкапы.

Остальные параметры носят опциональный характер.



##################################################################

# Переменные, определяемые пользователем

##################################################################

# Имена ВМ для бэкапа. При наличии нескольких имён следует использовать запятую (обязательный параметр). Например, $VMNames = “VM1”,”VM2”

$VMNames = ""

# Имя сервера vCenter или хоста, кластера, где находятся ВМ (обязательный параметр)

$HostName = ""

# Папка для бэкапов. Например, C:\Backup (обязательный параметр)

$Directory = ""





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



# Уровень компрессии(опционально; возможные значения: 0 – выкл., 4 – рекомендованный для дедупликационных хранилищ, 5 - оптимальный, 6 - высокий, 9 - максимальный)

$CompressionLevel = "5"

# VMware Tools Quiescence. «Заморозить» ВМ при создании снапшота (опционально; на машине должны быть установлены VMware Tools. Возможные значения: $True/$False)

$EnableQuiescence = $True

# Время хранения (опционально; по умолчанию, файлы VeeamZIP не удаляются, а хранятся в указанной папке неограниченное время.

# Возможные значения: Never, Tonight, TomorrowNight, In3days, In1Week, In2Weeks, In1Month)

$Retention = "Never"





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



##################################################################

# Настройки уведомлений

##################################################################

# Включить уведомления (опционально)

$EnableNotification = $True

# Сервер SMTP

$SMTPServer = ""

# Отправитель

$EmailFrom = ""

# Получатель

$EmailTo = ""

# Тема

$EmailSubject = ""







Отчёт выглядит следующим образом:







Экспериментируя со значениями переменных, можно найти ту комбинацию, которая удовлетворит именно вашему представлению о прекрасном. К примеру, если вы хотите, чтобы бэкапы были удалены через две недели, поставьте переменной $Retention значение “In2Weeks” и так далее.

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



Расписание. Надежное, как швейцарские часы



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

Самый простой из известных мне способов запускать скрипты по расписанию – это Windows Task Scheduler.

Открываем его и переходим к созданию Basic Task.







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

Следующая страница – Task Trigger.

Здесь всё просто и интуитивно понятно. Нужно решить, как часто нам хотелось бы создавать бэкапы (в английском под это дело есть умная аббревиатура – RPO, Recovery Point Objective), и отразить наши желания в виде заданных настроек.

Самый распространенный вариант – создание бэкапа раз в сутки.







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







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







В соответствующее поле вводим следующую команду:

Powershell –file “Путь к файлу Veeamzip.ps1”









Ну, вот и всё! Если вдруг вспомнили, что нужно внести кое-какие изменения в только что созданную задачу, то ставим флажок “Open the Properties” перед тем, как нажать “Finish”.







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







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



Вместо послесловия



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

До новых встреч!



Полезные ссылки





Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/278223/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Резервное копирование и перенос данных в браузере Vivaldi

Понедельник, 29 Февраля 2016 г. 21:08 (ссылка)

image



Всем привет!



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



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



Где всё лежит?



Это первый момент, который нужно знать. В Windows все пользовательские данные (ну, или почти все) хранятся в профиле пользователя, который при дефолтной установке находится примерно здесь:



C:\Users\_имя_пользователя_\AppData\Local\Vivaldi\User Data\



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



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



/home/_имя_пользователя_/.config/vivaldi-snapshot/



Режима Standalone в Linux-версии браузера нет — ранее мы уже рассказывали, почему это так, а также предложили способы обойти это ограничение. Но если вы воспользовались нашими советами (или знали решение и раньше), то должны уже догадаться, где искать пользовательские данные в этом случае.



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



Привет от корпорации добра



Но не только Apple заботится о своих пользователях. Не меньшую заботу проявляет и компания Google, волею судьбы ставшая основным разработчиком ядра Chromium, которое используется в Vivaldi. Впрочем, точнее это будет назвать «беззаботностью» — чтобы соблюсти политкорректность. Дело в том, что режим установки Standalone никак не предусмотрен в коде Chromium — видимо, про то, что пользователи иногда предпочитают устанавливать любимые приложения на USB-накопители и таскают их везде с собой, менеджеры Google не ведают, поэтому часть персональных данных пользователей сохраняется в недрах операционной системы. В частности, это пароли, сохраняемые пользователями в браузере и используемые для входа на веб-сайты, требующие регистрации.



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



Ближе к делу



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



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



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



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



Bookmarks — закладки

Cookies — собственно, Cookies с посещённых сайтов

Favicons — фавиконки закладок и посещённых сайтов

History — история посещённых сайтов

Login Data — логины к сайтам, требующим авторизации

Notes — заметки

Shortcuts — настройки комбинаций быстрых клавиш

Top Sites — данные с посещённых сайтов (включая эскизы Экспресс-панели)



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



В качестве заключения



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



Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/277741/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Symantec Backup Exec: восстановление Oracle, установленного на Linux

Среда, 17 Февраля 2016 г. 17:19 (ссылка)


В первой части было описано, как сделать резервную копию БД Oracle установленной на Linux средствами Symantec Backup Exec, теперь рассмотрим как из этой копии восстановить данные. Как и с резервным копированием не все так просто и очевидно. Читать дальше →

https://habrahabr.ru/post/277425/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<резервное копирование - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda