В нашем предыдущем посте мы рассказали историю Acronis: как все начиналось больше 10 лет назад. Кому-то, вполне возможно, она показалась впечатляющей, кому-то — просто интересной, а в действительности — это история компании, которая когда-то поднималась из простых серых зданий, переживала вместе со страной кризис за кризисом и осваивала новые рынки. В целом, мы давно заметили, что компании с особым духом, с неповторимым драйвом притягивают таких же людей, которые приходят, говорят «Это моё!» и остаются на долгие годы. Таким и есть Станислав Протасов, сооснователь и глава разработки Acronis. Кстати, 27 апреля (уже сегодня) Станислав выступит с открытой лекцией в своей альма-матер, в МФТИ. Но об этом чуть позже.
Рубрика «бэкапы» - 3
Человек в стиле Acronis: первая лекция в МФТИ (с онлайн-трансляцией)
2016-04-27 в 13:25, admin, рубрики: acronis, Блог компании Acronis, Inc, бэкапы, Восстановление данных, лекция, МФТИ, хранение данныхrm -rf: легкий способ уничтожить свой интернет-бизнес и свою репутацию
2016-04-15 в 8:31, admin, рубрики: linux, бэкапы, информационная безопасность, операционные системы, хостинг-провайдерыОдной командой владелец небольшого хостинг-провайдера удалил данные клиентов и бэкапы
Фото: independent.co.uk
На днях пользователь сайта Serverfault разместил на ресурсе интересный вопрос. Марко Марсала (Marco Marsala) спросил у других пользователей, можно ли после запуска команды rm -rf {foo}/{bar} оперативно восстановить данные. Как оказалось, Марсала является владельцем небольшой хостинг-компании, обслуживающей около 1500 клиентов. Для управления данными и автоматизации процессов он использовал Ansible.
В один из вечеров Марсала случайно ввел команду rm -rf {foo}/{bar}, запустив ее на всех серверах. Переменные {foo}/{bar} пользователь не задал. Изначально Марсала хотел удалить определенные директории на различных серверах, но из-за указанной выше проблемы удалилось все. При этом носители с бэкапами были подключены физически и подмонтированы, поэтому и эти данные были удалены.
Читать полностью »
Легенда о международном авось
2016-03-31 в 13:02, admin, рубрики: acronis, Блог компании Acronis, Inc, бэкапы, день резервного копирования, защита данных, конкурс, резервное копирование, хранение данных Признанный мастер бэкапа — ящерица. Отбросив свой хвост при форс-мажорных обстоятельствах, вскоре она отращивает новый. Это эволюционно заложено природой и не требует от земноводного особых усилий. Отдельные явления восстановления органов или клеток встречаются и у других животных, в том числе у homo sapiens. Однако сегодня ситуация поменялась и у человека, в отличие от ящерицы, появилась ещё одна значимая ценность — информация, а именно данные, которые он бережно собрал, накопил, и… А вот что происходит с ними дальше, зависит от того, насколько homo соответствует званию sapiens. Как вы уже догадались, соответствуют не все. Не даром же придуман World Backup Day, который празднуется как раз сегодня.
Итоги конкурса внутри!
Читать полностью »
Километры логов и восстановление баз данных на 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.
Читать полностью »