Первое апреля — день, когда все смеются, а разработчики и админы могут плакать, потому что 31 марта, во всемирный день бэкапа, происходит лютый шабаш хакеров, мошенников, интернет-хулиганов и всех тех, кто не против попробовать на прочность IT-мир. Мы попросили пользователей Хабра рассказать о своих факапах с бэкапами, чтобы другие могли поучиться в том числе на чужих ошибках. И, конечно, желательно их не повторять. Ну и, конечно, за такую информацию положены симпатичные призы.
В конце статьи проголосуйте сердцем и умом за самую жуткую и поучительную историю, три самых небезопасных автора получат призы от компании RUVDS:
👩🏻🚀🛰️ каждый победитель получит 5000 рублей на бонусный баланс и свитшот с автографом космонавта.
А самая заплюсованная история, рассказанная в комментариях, получит мерч от Хабра. Не стесняйтесь делиться опытом!
1. Исправил правильное на неправильное
Один знакомый хранит на жестких дисках коллекцию фотографий, которую долго собирал и продолжает понемногу увеличивать. Так как потерять её не хотел бы, он периодически переносит всё на внешний жесткий диск, который использует для резервных копий. Так как фотографий очень много, их объём приличный, и каждый раз после записи очередной резервной копии он старую удаляет (мол, зачем хранить два дубля на одном и том же диске). Недавно он обнаружил, что некоторые фотографии в некоторых папках не открываются. Вероятно из-за повреждения диска. Пошёл смотреть в резервной копии: оказалось, что там точно эти же фотографии тоже не открываются. Вероятно, за долгую историю они когда-то были повреждены, но это не было вовремя замечено, и в резервную копию были скопированы уже повреждёнными. Вывод напрашивается неутешительный: или каждый раз перед копированием проверять на работоспособность все тысячи файлов, или каждую резервную копию записывать вместе со старой, а не вместо её.
CBET_TbMbI
2. Классика: rm -f
Это случилось со мной на втором курсе института. Я работал над сложным курсовым проектом по расчету электрических цепей. Я использовал Ubuntu и имел множество файлов с данными, файлами Mathcad и черновиками отчета. За день до дедлайна я уже сделал отчет, готовый к защите.
Я решил, что мне не нужны черновики в папке с курсовым проектом, и выполнил в ней команду "rm ./*". Мне потребовалось всего несколько секунд, чтобы понять, какую ошибку я совершил...
Это была веселая ночь восстановления по памяти всего курсового проекта. На следующий день я защитил его на «отлично». Этот опыт научил меня делать больше бэкапов.
Теперь я всегда рассказываю эту историю своим коллегам, чтобы они тоже делали больше резервных копий.
korolaab
3. У вас флешка качается
Привет, как-то я сохранял свои учебные работы на флешке с шатающимся usb-портом. В нужный момент флешка не отобразилась на ПК, и все пришлось делать снова на месте. Благо я помнил, как все это делал! Но по итогу флешка заработала. Этим же днём я нашел запасную флешку и переписал на неё всё. А потом я стал сохранять работы ещё и в облаке, потом с ними было проще работать с телефона. А ещё позже я взял внешний жёсткий диск и сохранил туда свой учебный архив, фото, видео и прочие документы с ПК. Таков мой путь к безопасности информации!
Манагер
4. Все яйца на СХД
Да вот прям сейчас марлезонский балет происходит. Заказчик держит продуктивные данные почтового сервера на схд, там же лежит копия всех настроек. Но архивацию почтовых баз он не смог настроить, поэтому их резервные копии делает снимком соответствующей виртуальной машины. То есть точкой отказа является по-прежнему схд.
На прошлой неделе железка разобралась. Мы все героически спасаем неразумного вторую неделю.
smex5a6c6f
5. Подтяните сети
Как-то раз переезжали с лабы vmware на более новую версию. В тот момент у меня находилось около двух десятков активных стендов со всяческими образами под определенные задачи, на возведение конфигураций которых было убито много месяцев. Миграция прошла нормально. Но оказалось, что сетевые интерфейсы обнулились в новой лабе. А я как раз сетевик — почти все стенды так или иначе были связаны с сетью. Пришлось повспоминать архитектуру, поковырять маршруты с вланами, но в конце концов, я вернул все стенды в рабочее состояние (ну кроме одного, но его было уже не жалко удалить :) ). Мораль сей басни такова: бэкапьте не только сам продукт или объект, с которым вы работаете, но и его сетевую инфраструктуру.
Костя
6. Лёгкий 1С-ный испуг
По 1С:Предприятию 7.7 ПУБ. На предприятие в предбанкротном состоянии квалифицированные работники шли неохотно. Так приняли молодого Главного бухгалтера, которая в один прекрасный момент зашла в закрытый период и неожиданно для себя перепровела один документ. Сообщила об этом только через несколько дней, когда заметила, что «итоги не пошли». А предприятие всё это время активно работало. Хорошо, что есть Инфостарт, и одинэсниками много было сделано для доведения 1С 7.7 до нормального состояния применением внешних компонент. Доработал некоторую сырую обработку оттуда, которая в результате в ближайший выходной сработала как надо: был восстановлен бэкап на момент перед инцидентом, из поломанной базы по OLE были перенесены в целевую все документы и справочники, которые редактировались, создавались или удалялись в период, начиная со времени исходного бэкапа до вечера последнего рабочего дня, но с датой документа только в открытом периоде. При таком подходе, естественно, проблемный документ был исключён из обработки. Потом, правда, пришлось всё самому выборочно проверять, поскольку, к кому ни обращался на предприятии, все с удивлением спрашивали: «А разве что-то поменялось? Всё так и должно быть». Тогда помогла самописная система резервного копирования на скриптах. Хранил бэкапы 400 дней :)
kvk-2019
7. Сломанный мир
Как известно, админы делятся на два типа:
-
те, кто ещё не делает бэкапы
-
те, кто уже делает бэкапы
-
те, кто ещё и проверяет, что бэкапы не битые
-
наконец, те, кто, не имея бэкапов, грохает базу на проде для профилактики
И вот сделал я как-то такую неубиваемую базу. Подключил к ней веб-сервис коллаборативного рисования на карте мира. Но в нём закралась ошибка, которая добавляла в базу геометрию в немного кривом виде, отчего логика рендеринга ломалась. В результате после долгой загрузки не показывалось вообще ничего.
Не долго думая, я полез на прод и просто стёр все данные, чтобы очистить мир от скверны (благо, это ещё бета-версия и сохранность шедевров наскальной живописи мы не гарантируем) и, разумеется, поправил код, чтобы сохранял всё правильно.
Но я не учёл, что база-то у меня неубиваемая.. . Через несколько дней приложение открыл пользователь, что «видел» сломанную геометрию ранее. И вся она автоматически перелилась с клиентского устройства на сервер, вновь всё сломав.
Решилась эта проблема лишь переводом сервиса на новый корень мира. Теперь у нас в базе есть старый сломанный мир, и новый чистенький. Надеюсь, старый когда-нибудь можно будет удалить, и он больше не восстановится. Но для этого нужно дождаться, пока все свидетели старого мира увидят новый корень.
nin-jin
8. Художника обидеть может каждый
Я художник, не любящий рисовать одно и то же и доделывать картинки. У меня была программа с более 400 рисунков, и минимум 50 из них были точно не доделаны/не сохранены. В один день мой телефон сбросился до заводских настроек САМ ПО СЕБЕ (спасибо, китайский поко), удалив абсолютно всё, над чем я годы трудился…
У меня психологическая травма, спасибо большое. Это случилось почти год назад, и мне всё ещё тяжело смириться.
Согба
9. Чёт зациклилась
Настроили новую систему резервного копирования, потестировать. Настроили несколько заданий. Сначало работало параллельно основной системе, да и работало неплохо. Виртуальные машины были небольшого объема, все работало как часики.
Решили потестировать на более крупной машинке, объемом 10 тб. Добавили новое задание, оставили работать. Бэкап прошел, проблем не возникло. На старой системе приостановили бэкап данной вм, железо было старенькие, и задание выполнялось более 2-х суток. На новой же системе, что в тесте, выполнение задания занимало 1,5 дня.
Прошла неделя, у нас был полный бэкап и 5 дифференциальных. Все отлично, думали мы, и переживать никто не собирался. Но.. ведь всегда есть маленькое но...
Понедельник, утро, поступает заявка, что коллеги не могут получить доступ к виртуальной машине.
Начинаем выполнять диагностику... Видим следующее: у виртуальной машины с выходных идёт цикличное создание контрольных точек (снапшотов). Один из коллег принимает решение остановить этот процесс... При запуске получаем консолидацию вм, так как нарушена целостность контрольных точек.
Итог, сломанная вм и откат на 1,5 недели.
Частично данные потеряли.
Теперь к бэкапам все относятся более строго.
В любой ситуации получаем или опыт, или результат.
Settingh
10. Сгорел бэкап, гори и data
Давно это было, поучительно, поэтому не стыдно рассказать. У меня как-то сгорел сервер, ну не в смысле «сгорел», а сгорел в пожаре в дата-центре. Что удивительно, бэкап дата-центр хранил там же, поэтому и он сгорел тоже. Еще прекраснее, что на тот момент я не пользовался системами контроля версий, а просто раскидывал код по нескольким винтам от случая к случаю. Поэтому, когда произошло ЧП, оказалось, что у меня нет не то что последних версий, но и много месяцев назад.
Это история реального проекта typograf.ru. C тех пор он восстановлен, но возвращать его к тому состоянию, до пожара, уже нет сил, времени и желания.
Spearance
11. Хакатон на горячую голову
Тоже есть история: участвовал в CV хакатоне, поставил там label studio для разметки данных и настроил бэкап (он хранился на сервере), на второй день закончилась память, и я случайно, по глупости, не добавил место на диске, а подключил новый, на больше гигабайт. Да, вы всё правильно поняли: бэкап не сохранился🥲. Хакатон, к сожалению, мы проиграли, это был AI Energy Hackathon.
Gerbylev
12. Не на нашей стороне
Купил pdf редактор PDF-XChange. Из-за бага в нем (подтвержденный баг) все данные на ssd были стерты в течение нескольких секунд, в том числе черновик работы на звание кандидата наук. На диске образовались бедбоки, и при попытке чтения появлялся bsod. В рековери центре не смогли восстановить нужные мне данные. С тех пор делаю бэкапы регулярно и периодически их проверяю. PS: Кандидатскую защитил.
VKey
13. На краю тотального краха
Я устроился в айти-компанию системным администратором в прошлом году. До этого уже работал сисадмином, но опыт был не очень большой. Как мне позже рассказал мой руководитель, из всех кандидатов на работу взяли именно меня, потому что в конце собеседования я попросил повторить и записал вопросы, на которые не ответил. Ему показалось, что это признак большой ответственности, и я тот человек, который докопается до решения задачи в любом случае, а нехватку опыта и знаний компенсирую усердием:)
Когда я вышел на работу, на меня свалилась инфраструктура большой компании: с серверами виртуализации, контроллером домена, серверами баз данных и шлюзом — магическим pfsense на ещё более магической freebsd. А ещё моргающий красненьким индикатор диска на одном из серверов виртуализации. А в штате я был совсем один!
Работы поначалу было так много, что голова болела от новой информации, я погружался в каждую проблему и делал всё, чтобы решить каждую заявку. На некоторые проблемы уходил не один день, когда ни один совет с форумов не срабатывал и приходилось по второму кругу идти по вкладкам в интернете в поисках решения. А через какое-то время индикатор на диске сервера виртуализации уже перестал моргать и теперь светился красным постоянно. И хоть я работал много и усердно, старался за всем успеть и уследить, но за этим диском я все-таки не уследил. Но первый вышел из строя и не он...
В один из обычных дней я пришёл на работу и увидел, что на шару (файловую помойку) нет доступа. После неудачной попытки пингануть сервер я пошёл в серверную и увидел, что тот не может стартануть: он по настроенному самоподъему включался на несколько секунд и неожиданно отключался; и так по кругу. Блоку питания пришла хана. А вместе с ним слетели и настройки программного рейда: диски перешли в статус offline member, а рейд статус — failed.
И вот тут я впервые понял, что у меня спустя полгода работы нет на руках ни одного бэкапа ни одного сервака!
Рейд восстанавливал, отсоединяя все диски, включая сервак, потом выключение, все диски подключил и опять вкл. После проделанных манипуляций рейд прошёл ребилд, и работа восстановилась. Жаль, нервные клетки ребилд не умеют проделывать :) Сбор информации, попытки слить образы, консультации со специалистами по восстановлению заняли неделю.
Когда всё поутихло, я твёрдо решил, что без бэкапов больше работать не собираюсь, но не успел! Оказывается, я пропустил момент, когда на том самом сервере виртуализации с красным индикатором диска начал моргать второй диск! Сломя голову начал пытаться снимать бэкап со всего сервера, как вдруг этот второй диск подыхает прямо во время резервного копирования! Это был крах!
Порядка 15 виртуальных машин, среди которых контроллер домена, электронный документооборот компании за 10 лет работы, и на других —действующие проекты с заказчиками...
Конечно, я ответственность всю беру на себя, хоть и говорил о том, что срочно нужно место для бэкапов, всё равно мог своими силами организовать банку и потихоньку сливать туда резервные копии.
Много узнал про 5 рейд. В частности, что, когда выходит из строя 2 диска из 4, ломается весь рейд. Что ребилд в такой ситуации ни в коем случае делать нельзя.
Смогли восстановить информацию только с помощью профильной компании, которая занимается восстановлением. Когда они мне позвонили после диагностики и сказали, что получилось слить образы и файловая структура не пострадала, я был счастлив!
Не нужно вам испытывать такие нервы. Ребят, делайте бэкапы! Я рад, что появилась возможность поделиться этой историей, когда практически друг за другом чуть не умерли 2 важных для организации ресурса и оба раза мне повезло! Но связанный с этими событиями стресс я запомню надолго. Спасибо, что прочитали!
Jodanear
14. Не на нашей стороне — 2
Acronis Backup, версию сейчас не могу сказать, дома пишу. Бэкап сваливается с ошибкой. Кумулятивный отрабатывает нормально, инкрементальные — с ошибкой.
В чём соль: если в имени файла есть перед расширением пробел или лишняя точка... то инкрементный бэкап сваливается. Пользователь сделал 2 папки: одна с нормальным именем, вторая — с таким же, плюс пробел в конце.
Долго не могли найти корень ошибки.
strvv
15. Исчезновение одной виртуальной жизни
Пожалуй, самая страшная история случилась пару лет назад, когда после 10 лет ведения страницы VK меня заблокировали навсегда из-за подставы хейтеров, но никто разбираться не стал. А все материалы, весь контент, все регалии и достижения, интервью, документальные фильмы и прочее обо мне я хранил эксклюзивно только в одном месте — у себя на личной странице вконтакте. Теперь потенциальным работодателям или какой-нибудь будущей жене, которую я ищу, будет сложно доказать, какой я крутой. Отсюда мораль: не кладите все яйца в одну корзину. И старайтесь всегда вести минимум 2 соцсети. Сохраняйте контент на компе или в облаке.
P.S. Сейчас я веду одноклассники, и меня там никто не трогает.
levashovigor
16. Главное — скорость реакции
Это был жаркий день в офисе разработки программного обеспечения, когда вдруг все экраны компьютеров погасли. Паника охватила нас, когда стало ясно, что произошел крупный сбой в хранилище данных. Все ценные проекты, документация и исходный код были в опасности.
Без момента колебаний наша команда принялась за работу. Мы спешили восстановить данные, борясь со временем. Некоторые из нас вручную пытались восстановить файлы, пока другие настраивали временные резервные копии на других устройствах.
В это время руководитель компании, узнав о произошедшем, принял решительные меры. Он вызвал экстренное совещание и взял на себя организацию работы по восстановлению данных. Было принято решение немедленно внедрить автоматизированную систему резервного копирования.
Часы напряженного труда пролетели незаметно. К полудню удалось восстановить большую часть потерянных данных, благодаря настойчивости и эффективным действиям команды. Новая система резервного копирования сработала как часы, и даже в случае новых сбоев данные были в безопасности.
Этот инцидент стал для компании серьезным уроком. Он продемонстрировал важность быстрой реакции, согласованности действий и надежности системы резервного копирования. В конце концов, инцидент сделал нашу команду сильнее и лучше подготовленной к будущим вызовам :)
kamilka777
А как у вас случалось?
Автор:
Exosphere
