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

Итоги конкурса внутри!
Читать полностью »
Рубрика «бэкапы» - 4
Легенда о международном авось
2016-03-31 в 13:02, admin, рубрики: acronis, Блог компании Acronis, Inc, бэкапы, день резервного копирования, защита данных, конкурс, резервное копирование, хранение данныхКилометры логов и восстановление баз данных на MS SQL
2016-02-20 в 14:52, admin, рубрики: Microsoft SQL Server, MS SQL, QMB, Softlab, XML-план, Администрирование баз данных, Блог компании СофтЛаб, бэкапы, восстановление, Восстановление данных, резервное копированиеИли как без труда восстанавливать базы данных из длинной цепочки бэкапов
Форс-мажоры, или как люди теряли свои данные
2014-02-28 в 8:30, admin, рубрики: Блог компании «ua-hosting.com.ua», бэкапы, ит-инфраструктура, потеря данных, хостинг, метки: бэкапы, потеря данныхБородатая присказка гласит: админы делятся на тех, кто не делает бэкапы, и тех, кто уже делает. У большинства осознание необходимости делать резервные копии приходит после крупной личной потери данных. И, несмотря на обилие душещипательных историй о том, как люди теряли всё, до сих пор многие продолжают надеяться на то, что бэкапы кто-то сделает за них. В качестве напоминания о неверности такого подхода, я хочу привести несколько примеров того, как люди совершенно неожиданным образом лишались своих данных или были на грани этого.
Облако.Mail.Ru + EncFS для резервного копирования домашнего фотоархива
2014-01-18 в 8:21, admin, рубрики: backup, encfs, mac os x, бэкапы, информационная безопасность, Облако Mail.ru, хостинг, шифрование данных, метки: backup, encfs, mac os x, бэкапы, Облако Mail.ru, шифрование данных
В конце прошлого года Mail.Ru вновь (впервые с 1997 года ;) выпустила революционный продукт — облачное хранилище, первым активным пользователям которого бесплатно выдают 1 Тб. 1 Терабайт — по меркам начала 2014-го года это совершенно эпический объем, по крайней мере в масштабе национальной отрасли ИТ. Ради справедливости можно отметить, что некоторые китайские компании дают и больше, однако практическая применимость таких предложений для большинства читателей Хабрахабра выглядит сомнительной.
Небольшим изъяном актуальной версии Облака по мнению многих моих друзей и коллег выглядит то, что Облако (по крайней мере официально) не поддерживает WebDAV. Это не позволяет «из коробки» использовать шифрование с помощью простых и популярных в народе продуктов вроде Boxcryptor. Поскольку сам по себе Boxcryptor — это всего лишь удобная графическая надстройка над encfs+fuse, я решил для себя и для друзей составить короткую и простую инструкцию, как эффективно шифровать данные бэкапов в Облаке.Mail.Ru
Постановка задачи
Я продвинутый фотолюбитель. Мой фотоархив насчитывает примерно 600Гб данных, причем примерно половина из них — это выполненные в высоком разрешении сканы родительских слайдов, начиная с 1957 года. Почти все хранится в NEF+CR2 (это raw-форматы Canon и Nikon), каждая фотокарточка занимает от 15 до 60 мб. Иными словами, бесплатный терабайт от Flickr меня совсем не устраивал в частности из-за невозможности хранить необработанные исходники фото. Начиная с 2008-го года, резервирование архива выглядит так: раз в году я покупаю современный жесткий диск стоимостью 100 евро и копирую на него все содержимое предыдущего диска, а старый HDD отправляется «на пенсию» в медиа-сервер, который включается 3-4 раза в год. У этого подхода много достоинств (несмотря на смертность жестких дисков, данные еще ни разу не пропадали), но есть огромный недостаток — физическое расположение хранилища.
Я много путешествую по миру, и за последние 10 лет суммарно провел в России (где находится медиа-сервер и стопка «отставных» HDD) не более 4-х лет. Иногда случаются казусы, связанные с потерей внешних винчестеров — так я потерял значительную часть архива фотографий 2012-го года, которые банально не довез до своего дома на родине. На словах решение простое — «go cloud», а вот на деле тарифы всех мало-мальски удобных сервисов, позволявших заархивировать 1Тб оригиналов фотоизображений, были долгое время прямо-таки заоблачными.
И вот 20 декабря 2013 года нам было объявлено о том, что все желающие обладатели ящика на mail.ru могут получить в подарок 1 терабайт. Бесплатно. Для любых файлов. Но только у многих возникают вопросы, как хранить свои данные в облаке в зашифрованном виде.
У Линуса Торвальдса сломался SSD
2013-09-11 в 20:59, admin, рубрики: linux, ssd, бэкапы, Восстановление данных, Линус Торвальдс, Накопители, ядро Linux, метки: ssd, бэкапы, Линус Торвальдс, ядро Linux 
Свой первый SSD на 80 ГБ Линус купил в 2008 году
Внезапная поломка SSD-накопителя на основном компьютере Линуса Торвальдса привела к тому, что работу над очередной версией ядра Linux 3.12 пришлось временно прекратить.
Торвальдс пока не смог ничего восстановить с погибшего SSD. Он говорит, что успел отправить в ветку почти всю сделанную работу, так что сам практически ничего не потерял. Но есть проблема с чужим кодом, который ему прислали для включения в ядро, а он ещё не успел этого сделать.
Читать полностью »
В IFTTT появилась поддержка Google Drive
2012-09-05 в 12:26, admin, рубрики: google drive, if this then that, IFTTT, бэкапы, Веб-разработка, логи, Облачные вычисления, Социальные сети и сообщества, метки: google drive, IFTTT, бэкапы, логи
Популярный сервис автоматизации IFTTT (If This Then That) позволяет создавать «рецепты» — простые задачи вида «Если я опубликовал запись в Фейсбуке, то об этом надо написать в Твиттер». Теперь он работает и с облачным хранилищем Google. Доступны такие действия, как добавление файла, создание документа, добавление информации в конец документа и строки в конец электронной таблицы.
На ifttt.com уже есть почти сотня готовых рецептов для работы с Google Drive: автоматическая архивация твитов, фотографий из Facebook, Flickr и Instagram, ведение логов своей сетевой активности в электронных таблицах. Есть возможности и поэкзотичнее — можно завести таблицу, в которой будет фиксироваться погода за окном или курсы акций.
Читать полностью »
Amazon Glacier: клиент на Perl с многопоточной/multipart закачкой
2012-08-27 в 17:48, admin, рубрики: Amazon Glacier, Amazon Web Services, AWS, perl, бэкапы, Восстановление данных, метки: Amazon Glacier, aws, perl, бэкапы 
Amazon Glacier
Вкратце — Amazon Glacier — это сервис с очень привлекательной ценой сторейджа, созданный для хранения архивов/бэкапов. Но процесс восстановления архивов довольно сложный и/или дорогой. Впрочем, сервис вполне пригоден для secondary backup.
Подробнее про Glacier уже писали на хабре.
О чём пост
Хочу поделиться Open Source клиентом на Perl для синхронизации локальной директории с сервисом Glacier, также расказать о некоторых ньюансах работы с glacier и описать workflow его работы.
Читать полностью »
Amazon Glacier: хранилище данных по $0,01 за 1 ГБ в месяц
2012-08-21 в 8:09, admin, рубрики: Amazon Glacier, Amazon Web Services, архивы, бэкапы, Восстановление данных, резервное копирование, системное администрирование, хранение данных, метки: Amazon Glacier, архивы, бэкапы, резервное копирование, хранение данныхСегодня начал работу новый проект Amazon Glacier: долговременное хранилище в облаке по невысокой цене $0,01 за 1 ГБ в месяц. Идеально подходит для хранения бэкапов и больших архивов, к которым не нужен частый доступ. Извлечение данных из Glacier занимает от 3,5 до 4,5 часов.
Как везде в AWS, пользователь оплачивает только тот объём ресурсов, которые реально использует, никакой абонентской платы и прочих хитростей. Загрузка и извлечение архивов, мониторинг статуса возможны через Amazon Glacier APIs. Все файлы автоматически шифруются AES 256 и дублируются в разных дата-центрах, прежде чем APIs возвращают ответ SUCCESS.
Читать полностью »
Резервирование больших данных
2012-06-21 в 10:33, admin, рубрики: datawarehouse, Администрирование баз данных, базы данных, Блог компании «LifeStreet Media», бэкапы, хранилище данных, метки: datawarehouse, базы данных, бэкапы, хранилище данныхПри проектировании и эксплуатации нашего хранилища данных, несколько раз возникал вопрос, как делать бэкапы или репликацию. Я на него неизменно давал один и тот же ответ — никак. Объясню немного почему.
Бэкапы больших баз данных (от сотен гагабайт и выше) достаточно бесполезное занятие по одной простой причине: восстановление из бэкапа может занять дни. Если база данных используется постоянно для ведения бизнеса и в нее непрерывным потоком грузятся данные — это неприемлимо. Несколько лучше обстоит дело в случае инкрементального бэкапа на резервную систему, которую можно включить прямо поверх бэкапа. Однако, такой способ подходит не для всех баз данных, а только на тех, которые не меняют однажды записанные на диск файлы. Например, для MySQL этот способ плохо подходит, все таблицы лежат или в едином tablespace (InnoDB), или в отдельных файлах (MyISAM). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.
Иногда для поддержания резервной системы используют репликацию. Но надо понимать, что репликация довольно сильно просаживает производительность, так как требует записи бинарного лога, а если репликация синхронная, то и синхронизации. В аналитических приложениях с большим потоком данных, когда требуется постоянно грузить в базу данных тысячи или десятки тысяч записей в секунду, это может быть неприемлимо.
Что же делать?Читать полностью »


