Рубрика «бэкапы» - 4
Километры логов и восстановление баз данных на 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). Для Вертики — это возможный вариант, так как данные записываются в безличных файлах, которые не меняются после записи, а только удаляются. Однако, в случае кластерных систем необходимо обеспечивать идентичную топологию основной и резервной систем. Также могут возникнуть проблемы с целостностью данных в случае сбоя основной системы.
Иногда для поддержания резервной системы используют репликацию. Но надо понимать, что репликация довольно сильно просаживает производительность, так как требует записи бинарного лога, а если репликация синхронная, то и синхронизации. В аналитических приложениях с большим потоком данных, когда требуется постоянно грузить в базу данных тысячи или десятки тысяч записей в секунду, это может быть неприемлимо.
Что же делать?Читать полностью »


