Первое апреля — день, когда все смеются, а разработчики и админы могут плакать, потому что 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
А как у вас случалось?
Комментарии (73)
wmlab
01.04.2024 18:16+30- Я случайно базу данных. К счастью, я сделал скриншот.
- Снапшот?
- Нет.
plFlok
01.04.2024 18:16+5знакомый рассказывал, как частично бд одного сайта восстанавливали по парсингу вебархива.
goshadub
01.04.2024 18:16"Как хранить данные в png, не привлекая внимания санитаров" https://habr.com/ru/articles/590469/
MountainGoat
01.04.2024 18:16+8Это что за чудесная система такая, что ошибка в редакторе PDF приводит к битым секторам на диске? DOS?
urvanov
01.04.2024 18:16+415. Исчезновение одной виртуальной жизни
Ну у себя-то на диске нужно было оригиналы хранить! Этот VK же пережимает небось всё под свои форматы в любом случае.
urvanov
01.04.2024 18:16+138. Художника обидеть может каждый
Тут вообще вопрос потери был просто вопросом времени, мне кажется. Рано или поздно телефон либо утонул бы, либо отказался бы включаться, либо его украли бы. А то, что он сам сбросился до заводских настроек - это всего лишь один из возможных сценариев.
nitro80
01.04.2024 18:16+2При том, что в телефоне зачастую есть облако от Google
hullaballoo
01.04.2024 18:16облако от Google
Бесплатное, места в котором всё-равно не хватает через несколько недель рисования.
YMA
01.04.2024 18:16+8Вывод напрашивается неутешительный: или каждый раз перед копированием проверять на работоспособность все тысячи файлов, или каждую резервную копию записывать вместе со старой, а не вместо её.
Вариант решения - бэкап должен обладать свойством самопроверки, а еще лучше - самовосстановления. Я тоже бэкаплю тысячи фоток, но после формирования пакета натравливаю на него MultiPAR (ранее QuickPAR). В итоге пакет можно быстро проверить на целостность, и в случае выявления небольшого повреждения - восстановить.
В один день мой телефон сбросился до заводских настроек САМ ПО СЕБЕ (спасибо, китайский поко), удалив абсолютно всё, над чем я годы трудился…
Буквально пару дней назад звонит сестра, айфон ночью засветился, выключился, и больше не загружался, вис на яблоке. Допрос с пристрастием привел к версии - место в хранилище практически закончилось (привет картинкам WA, telegram и т.д.), айфон на это ругался, но попытался поставить обновление и место закончилось совсем. Запуститься уже не смог, попытки недеструктивно восстановить систему ни к чему не привели, пришлось прошивать через DFU, с потерей всех данных. Бэкапа образа телефона не было, iCloud тоже был забит всякой мутью, вместо критичных данных.
"Ну я же тебе говорил, что нужно" "А у меня на ноутбуке места тоже нет".
Да, на ноутбуке у нее оказалось свободно 4 ГБ диска, все забито фотками и видео, опаньки, ждем следующий факап. :(
akhalat
01.04.2024 18:16+1Вариант решения - бэкап должен обладать свойством самопроверки, а еще лучше - самовосстановления. Я тоже бэкаплю тысячи фоток, но после формирования пакета натравливаю на него MultiPAR
+1 за MultiPar, тоже недавно открыл его и пользуюсь с удовольствием. У этой утилиты небольшая огласка, и мало кто про нее знает, хотя на практике она очень удобна. Ближайшее что есть по функционалу - информация для восстановления в winrar, по степени удобства сильно позади.
Только в описанной ситуации думаю мультипар бы не помог. Насколько я понял из описания, у него была полная и постоянно пополняемая коллекция фоток на основном диске, и регулярно делался ее бэкап на внешник. В какой-то момент основной диск стал сыпаться (или ещё как-то побились файлы), и часть фоток стали битыми. Очередной бэкап был сделан уже с битой инфой, а старый (с нормальной) удален для экономии места. И думаю прошло немало итераций таких бэкапов, прежде чем повреждения обнаружились. Здесь могло бы помочь только хранение очень старых версий бэкапов, или какое-то сравнение бэкапа не только с источником, но и со старым бэкапом (и то, настраивать надо было отдельно, т.к. это не отличить от замены файлов просто новой версией). В общем, трудноуловимая ситуация на самом деле. Если это реально произошло из-за того что диск посыпался - можно было отследить по статусу SMART (регулярно его проверяю для своих дисков). А если какая-то сторонняя прога, кривой скрипт или что-то ещё побило файлы, то практически никак.
rombell
01.04.2024 18:16+2Я держу два диска с холодным архивом фоток, и свежие не сортированные отдельно. Свежие бэкапятся еженедельно ещё в два места, перед переносом в архив считается CRC, ежегодно проверяется CRC на архивных дисках. Архивы лежат физически в разных местах.
Пока потерь нет.
Penumbral
01.04.2024 18:16Можете подсказать не очень знающему человеку: я пользуюсь FreeFileSync для инкрементного копирования некоторых данных с домашнего ПК на внешний жесткий диск. Там перед "зеркалированием" сначала проводится анализ файлов с обоих сторон, потом копируются/заменяются новые/обновленные файлы.
Если все файлы изначально были целы и программа решила что и её бэкап - идентичный - это ведь значит что файл не может быть битым? Просто у меня там тысячи папок и десятки тысяч файлов - проверять их все, очевидно, невозможно.
Могу ли я как-то улучшить/обезопасить процесс бэкапа?
Ambiphonic
01.04.2024 18:16+1А разве не помогло бы просто бекапить только новые фото, не трогая старые? Ведь проблема в том, что похоже все перезаписывалось, и однажды целое - стало битым на основном жд и с него уже была сделана битая копия.
dag_tech
01.04.2024 18:16+7Мир стал сложнее. В части бэкапов администраторы теперь делятся на заметно большее количество категорий:
Кто не делает бэкапыКто стал делать бэкапы
Кто стал регулярно делать бэкапы
Кто стал регулярно делать бэкапы в разные целевые ресурсы разных типов (на локальные и сетевые носители (разных типов, производителей, моделей), в облачные хранилища)
Кто стал регулярно делать вышеуказанное как минимум двумя разными инструментами (разных поставщиков систем резервного копирования (СРК)), или, по возможности, в стандартизированные форматы резервных копий
Кто в дополнение к вышеуказанному стал регулярно проверять и свежие и, с меньшей интенсивностью, исторические, бэкапы (а то всё было хорошо, но вдруг обновлённая СРК разучилась понимать свои же форматы N-летней давности; в этом же контексте – кто сохраняет установочные пакеты предыдущих версий СРК)
Кто стал перепроверять бэкапы, как указано выше, сторонними совместимыми средствами (а не только средствами самих систем резервного копирования – самопроверка это хорошо, но альтернативная проверка не помешает)
Кто, в дополнение к вышеизложенному, стал не только проверять бэкапы, но и регулярно (периодически?) проводить «учения» по восстановлению данных из бэкапов, со сверкой восстановленных данных, полученных из не менее чем двух источников – например, на одну и туже дату-время резервирования, из двух разных СРК, или сверять ранее синхронизированные «замороженные» данные и данные, восстановленные из резервной копии.
Дорого? Ресурсоёмко? Спокойствие ценнее.
fox_12
01.04.2024 18:16+10В серверной одного предприятия стояло две стойки с серверами. Нужно было обеспечить высокую надежность и доступность. Все работало - резервировалось, балансировалось, делались бекапы на сервера-хранилища с рейдами (в те времена еще облачные сервисы не были развиты). Все это хозяйство запитывалось через мощный бесперебойник, способный держать электропитание в течение как минимум 40 минут пока резервный генератор не запустится при необходимости. В общем почти все по фен-шую...
И вот эта вся надежность сыграла злую шутку. Глубокой ночью прорвало воду на техническом этаже, и вода потекла водопадом на серверные стойки. Охранник понимает всю серьезность ситуации и обесточивает серверную. Но бесперебойник продолжает работать, вентиляторы на серверах затягивают воду внутрь и щедро орошают всю электронику внутри корпусов...
Сервера начинают выходить из строя один за другим. Выходят из строя и сервера с бекапами... Бесперебойник держится до конца, пока поднявшаяся вода не зальет управляющую плату и он сам тоже не выйдет из строя...
Наутро аврал с полным разбором всех серверов, промывкой плат спиртом для вытеснения воды, сушка и сборка. Восстановление работоспособности. На удивление - порядка 75% парка серверов тогда восстановить удалось...
little-brother
01.04.2024 18:16+2Был у меня заказчик, который сказал - хочу волшебную кнопку EPO от APC :) Вот она бы точно помогла вашему охраннику (для этого и придумана).
Pochemuk
01.04.2024 18:16+5Нас лет 8 назад взломали по RDP. Аккаунт был практически не рабочим, поэтому ничего там особого не пострадало. Но злоумышленник запустил на этом аккаунте скрипт, который находил в сети все доступные шары и шифровал их содержимое.
Среди этих доступных этому аккаунту шар оказался диск на одном АРМ SCADA-системы, на котором находился рабочий SCADA-проект. По недосмотру дали к нему временно общий доступ для удобства настройки, а потом снять разрешения забыли (это был я, если что). SCADA зависла и больше не запускалась, разумеется.
Когда посреди ночи локализовали и нейтрализовали угрозу, встал вопрос о восстановлении проекта из резервных копий. Но оказалось, что инженер, создававший эти проекты, хранил их в разделе файлопомойки с общим допуском, а не с ограниченным личным или отдельским. Разумеется, зловредный скрипт тоже обнаружил эту доступную ему шару и зашифровал в ней всё.
Хорошо, что у этого инженера на компе сохранился проект двухмесячной давности. Запустили его. А этот товарищ две недели спешно восстанавливал нововведения за этот срок.
Так что, резервные копии не только должны быть, но и надежно храниться. Желательно, в разных местах.
Lazhu
01.04.2024 18:16+1Чтобы таких подстав не происходило, бэкапящая софтина должна находится на машине, недоступной из сети, и сама собирать отовсюду бэкапы, а не наоборот.
mayorovp
01.04.2024 18:16Ну, для файлов это само собой.
Но теперь объясните как настроить архивацию сегментов wal в подобном режиме...
Lazhu
01.04.2024 18:16+3Как хотите, но должна быть хотя бы одна копия, недоступная из сети. Как в комментарии ниже, например. Как известно, информация делится на сохраненную в оффлайне и потерянную
Naves
01.04.2024 18:16Мастер сервер кладет файлы в каталог в локальный каталог archive.
Реплика забирает файлы с мастера и удаляет их, например rsync --remove-source-files
Или мастер по расписанию сам удаляет файлы старше N-часов из archive.
Pochemuk
01.04.2024 18:16У нас сейчас так копии БД снимаются.
Сначала бекапятся на том же сервере внутренними механизмами SQL. Потом копируются по сетке на архивный сервер. А потом к нему подключается отдельно живущий на кладбище сервер (шутка ... - на складе рядом с кладбищем в 200 метрах от офиса) и стягивает эти бэкапы себе по FTP. Сам он закрыт роутером от всех внешних подключений, кроме необходимых для контроля работы.
Но всё равно существует временной зазор, в течение которого возможна порча бэкапов.
В идеале, при бэкапах должна на лету подсчитываться контрольная сумма и каким-то образом передаваться конечному хранилищу для контроля неизменности. При несовпадении - алерт. Но в SQL такого нет, а подсчитывать КС уже после завершения создания резервной копии - уже нет смысла.
Naves
01.04.2024 18:16+1Рядом с бэкап-сервером ставится SQL-сервер, на котором тестируется восстановление из бэкапа, с письмом о результате.
Pochemuk
01.04.2024 18:16О! Нашел демотиватор, который сделал после того случая. На картинке почти что я (слева) с тем инженером (справа):
GennPen
01.04.2024 18:16+3Когда занимался ремонтом мобильной техники, то часто приносили убитые вусмерть телефоны с просьбой вытащить информацию (в основном фотографии). Некоторые получалось частично оживлять для восстановления инфы, но подавляющее большинство не восстановимо. Приходилось объяснять людям, что если нет бэкапа - значит данная информация для них не столь важна что ее можно потерять.
feelamee
01.04.2024 18:16+1а как же cfdisk, которые ломает структуру файловой системы?
я один споткнулся на этом, когда только знакомился с линуксом?
garwall
01.04.2024 18:16+1можно подробнее?
feelamee
01.04.2024 18:16ставите допустим новую систему рядом со старой
вот пришло время создавать разделы. Ставим, конечно, archlinux (btw), поэтому никакого гуи у нас нет. Тут у вас несколько вариантов sfdisk, cfdisk, parted.
Самый интуитивный, я полагаю, cfdisk, так как он имеет tui интерфейс.
Заходите в него. Уменьшаете размер раздела, на котором у вас стоит /home допустим от первой системы, чтобы выделить место под новую систему. В итоге файловая система уменьшенного раздела повреждена...
Следующие 8 часов вы проведете за поиском способа для восстановления.
И, если вы неопытный новичок(коим я и был), сдадитесь, попращавшись со всеми вашими очень и не очень важными данными.
Возможно я тут ошибаюсь насчет cfdisk и это я где-то накосячил, но я уже и раньше слышал от других людей об этой проблеме.
GParted с этим легко справляется. Т.к. он использует libparted, то и parted полагаю тоже.
DaemonGloom
01.04.2024 18:16GParted конкретно - достаточно умный и ожидает неопытных пользователей. Всё остальное - честно уменьшает раздел, как ему и говорят. Parted тоже убьёт вашу файловую систему, если вы так сделаете.
Правильный метод - resize2fs на нужный раздел с указанием нового размера чуть меньше желаемого, потом уменьшение раздела через любой менеджер, затем снова resize2fs для точного выравнивания конца файловой системы по концу раздела.
gruzoveek
01.04.2024 18:16+8Приняли стажера, а в качестве ментора поставили джуна, который сам вчерашний студент. Стажеру дали небольшую задачу для ознакомления, и он захотел тестовый сервак для погонять. Джун ему и выделил как бы ненужный сервер, для опытов. А это оказался клон сервера с данными для аналитиков. И когда у них что-то полетело на основном, они побежали на клон, а там вместо нормальных данных - кракозябры, пустые строки и матюки.
Так я в первый раз отучился матюкаться в тестовых данных.
mayorovp
01.04.2024 18:16+2Было бы лучше, если бы аналитики увидели совершенно нормальные, только ложные, данные?
ErshoffPeter
01.04.2024 18:16+7Ничего не написали про главный backup - про дублёров ключевых сотрудников. А без них и резервные копии не резервные копии, если в них никто не сможет разобраться.
arpeggio
01.04.2024 18:16+4Мне сразу вспомнилась история пиксар, как у них накрылся основной сервак, на котором все материалы по истории игрушек были и повезло, что одна из дамочек работала из дома и у нее была локальная копия относительно свежая.
nitro80
01.04.2024 18:16+5Прошлым летом NAS начал кричать уведомлениями, что один из жёстких дисков находится к критичном состоянии.
Бюджетная организация, денег традиционно нет. Спонсоров летом не найти, они лишь к концу года появляются.
К новому году сетевой диск перестал быть доступным, результат работы десятков людей за многие годы просто исчез. За восстановление данных платить опять некому. Да и не обещают ничего...
Вот так и живём...
Harpagon
01.04.2024 18:16+13Однажды в нашей тесной конторке программистов раздалось сочное "Б#%π§ть!", за столом ведущего программиста, к нему тут же подскочил начальник и повторил то сочное слово. Оказалось, что ведущий программист разбирал код какого-то запроса в Query Analyser, выделил фрагмент и случайно нажал кнопку "выполнить". Query Analyser и выполнил, именно выделенный фрагмент, где был запрос delete from <table>, но без условия, которое выделено не было... База оказалась рабочей, а не тестовой.
Я тогда был стажёром на испытательном сроке, спросил, что случилось, мне объяснили и я проникся. Но по счастливой случайности я всех спас тем, что у меня случайно оказался свежайший бекап именно той таблицы. У меня было задание сделать утилиту для работы с dbf файлами (были отделы с софтом на foxpro) и написание этой нудятины скинули на меня, утилита должна была провести манипуляции с dbf файлом, сделать пару отчётов и упаковать все в архив. И чудом именно в то утро я слил именно пострадавшую таблицу в dbf формат (там были все нужные мне типы данных), чтобы локально тихонечко пилить свою утилиту и мучать эту dbf-ку.
kvk-2019
01.04.2024 18:16По "6. Лёгкий 1С-ный испуг" добавлю (по памяти), если кому интересно, что не всё прошло "без сучка и задоринки". OLE имело свои ограничения, в частности целые числа там всегда передавались как вещественные, а число 0 в заготовке обработки, которую взял за основу, просто игнорировалось, насколько помню. В результате, в спецификациях "весело" было наблюдать вместо нулей NULL, или "Неопределено" (1С тут имеет несколько вариантов, вроде), не помню уж теперь. Но к счастью логику работы это не поломало. И ещё добавлю несколько слов. Люди работали, пока я готовился к ремонту. Они могли несколько раз исправить документы прошлого месяца, исправлять справочники и даже что-то удалить. Задача была, чтобы это всё учесть. Готовился интенсивно дней 5-6, вроде, судя по сохранившимся копиям версий обработки, а потом тренировался, контролируя вновь поступившие данные. Но сначала нужно было определить, когда возникла проблема и в чём заключалась. Вот для этого пришлось многократно разворачивать имеющиеся копии и сравнивать в них отчёты, а потом анализировать журнал регистрации. Именно по журналу регистрации (обычный текстовый файл, за исключением кодировки объектов), и удалось всё восстановить. Перенести его часть после исходного бэкапа в отремонтированную базу потом не представлялось возможным (условно идентификаторы объектов поменялись). Жалоб не поступало, хотя понимаю, что это не показатель. Но выборочная проверка дала некоторую долю уверенности. Изначально этот пост опубликовал у себя на Дзене.
Sergey_VR
01.04.2024 18:16+3Не совсем в тему, но хочу поделиться. У меня с бекапом была одна счастливая (в целом) история.
Для подготовки обновления потребовалась база от Заказчика. Размер бекапа 4 ГБ, а в упакованом виде сильно меньше, поэтому файл хранился в архиве. Распаковал и запустил восстановление, но SQL Server выдал ошибку. А базу эту я уже восстанавливал когда-то. Удивился, распаковал ещё раз и опять ошибка при восстановлении. Тут уж я испытал когнитивный диссонанс.
Как же так - я же точно помню, что успешно восстанавливал базу из этого архива! Или всё-таки не из этого архива? Может перепутал? Может 7-zip обновился и по другому распаковывает? Или Каспер проверяет на лету и курочит?
В конце концов решил сравнить контрольные суммы файла в архиве и распакованного. И вот тут я узрел чудо - контрольные суммы были разные. Распаковал ещё раз в другое место - контрольные суммы сошлись. В общем, жёсткий диск начал сыпаться и выдавал подобные чудеса.
К счастью, всё обошлось. Винт заменили и вроде больше ничего не сломалось. Но админ, ответственный за оборудование, поверил в это не сразу. Пришлось делать скриншоты контрольных суммм.
yarushka
01.04.2024 18:16+2Где-то году в 2010 была история. Как-то 28 декабря в последний рабочий день зашли в серверную ПРОСТО ПОСМОТРЕТЬ. Нужно было составить схему сети и для этого посмотреть коммутацию. Ничего даже не трогали, просто открыли дверь шкафа, а из-за плохо вставленного в один из двух блоков питания СХД кабеля контакты заискрили и одна полка отвалилась, несмотря на второй БП. СХД IBM DS4700. Бэкапа почему-то не было, по-моему незадолго до этого сервер бэкапов вышел из строя и мы ждали оборудование на замену.
После перезагрузки СХД массив не поднялся,из интерфейса тоже никак не поднимался.
Было потрачено много нервов, по дружбе один из интеграторов прислал специалиста по СХД IBM, но он тоже разводил руками.
На СХД вся жизнь компании. В итоге уже ближе к ночи, в cli пробую какую-то команду и система поднялась. Я был счастлив. Причём команда какая-то очень простая, которая просто LUN делает online.
Livefish
01.04.2024 18:16+1Дааа, была у меня история. Я школьник 15 лет, учусь на программиста сам. Около полутора лет пользуюсь Федорой. И после перехода на Линукс я очень много раз стрелял себе в ногу) Первый раз был после первой установки, когда я выделил 50 Гб места на всю систему, а потом до меня дошло, что маловато будет. У меня был дуалбут, поэтому я просто зашёл в Винду, открыл средство разметки дисков и отформатировать раздел, где был Линукс) В итоге загрузчик сломался, починить так и не смог, поэтому Винду пришлось переустановить тоже.
Второй случай был совсем недавно. Я уже почти полностью пересел на Линукс, Винду включал редко. Но на виндовском диске с ntfs были мои старые проекты, которые мне захотелось перенести на другой диск, уже с btrfs. Скачал драйвер, подмонтировал диск, а он read only. Мог бы скопировать всё, что нужно и потом забить, но я решил разобраться. Раньше же работало. Погуглив, выяснил, что из-за сетевой папки, которую я на этом диске настраивал на винде, файловая система находится в заблокированном состоянии. Для того, чтобы это состояние снять, можно было перезагрузиться, зайти в Винду, снести общий доступ, перезагрузиться и работать дальше. Или просто выполнить команду, которая за меня все сотрёт. Само собой, я начал искать эту команду. Открыл stackoverflow и случайно скопировал команду из вопроса, а не из ответа. Этой командой была wipefs... После перезагрузки ничего не загружалось. Беру livecd, пытаюсь починить, восстановил. Было страшно)
Самое фееричное было буквально две недели назад. Я использую timeshift для бекапов, узнал о нем из видео на Ютубе в духе "топ 10 обязательных программ для Линукса". Скачал, изучил, настроил бекапы каждый Бут, каждые пару дней, а раз в месяц полный, и счастливо забил. А потом пытался сделать второй монитор через xrandr, и сломал все. Судя по логам, dbus перестал загружаться вообще. Способа починить не нашел. Вспоминаю про бекапы, беру live cd, бекап на месте. Моему счастью нет предела, нажимаю кнопку восстановления и "ваша фс не соответствует формату бекапа, восстановление невозможно". Оказалось, для работы timeshift в btrfs должны быть сделаны partitions с названиями @home, @root и тп. В общем, схема для Ubuntu, как выяснилось позже. Само собой, при установке системы я этого не сделал, поэтому плакал мой бекап. А проверять восстановляемлсть мне мозгов не хватило)
Все закончилось хорошо, я купил ssd на террабайт, поставил туда свежую систему, уже правильно, а тот диск смонтировал и переносил нужные программы и данные по крупице через far) восстановил все, что нужно было, но опыт полезный конечно.
Думаю как-нибудь сделать из этих историй статью.
Когда-нибудь ты станешь немощен и слаб
Делай бекап, давай, делай бекап....
Pochemuk
01.04.2024 18:16Как говорил один анимешный персонаж: "Опыт приходит с болью".
Со временем боли становится меньше ... впрочем, есть те, которым она, наверное, нравится :D
Livefish
01.04.2024 18:16Боли становится меньше, но количество способов все сломать каждый раз меня поражает) Ходя удивляться, в прочем, нечему. Сам выбираешь свой путь. Ну я и выбрал, и мне даже нравится. Главное не потерять данные, а фиксы таких проблем - занятие очень даже интересное. Пока разбирался, почитал здесь же про устройство btrfs, cow механизм, systemd, устройство dbus, файловые системы. Накапливается своего рода база ошибок, с которыми потом проще справиться в разы самому или подсказать другому, если вдруг похожая проблема
A_Green
01.04.2024 18:16Ситуацию наблюдал университете, в далёком 2001 году:
Студент делал большую курсовую работу в "компьютерном центре" электротехнического факультета. Долго делал, наверное месяц. Когда пришла пора распечатывать курсовую, выяснилось, что дискета не читается... Самый большой шок нас ожидал когда выяснилось что второго экземпляра нигде нет: он всегда его редактировал прямо на дискете...
Другой дискеты у него просто не было, нигде на компьютерах не сохранял... Ему просто никогда не объясняли как надо делать правильно.
Кажется часто корень проблем с бэкапами кроется в этом: люди принимающие решения просто не представляют что это и зачем. Им обязательно надо всё подробно объяснять - "обозначать риски".
TRaMeLL
01.04.2024 18:16Я на каком-то форуме видел вопрос от человека, который спрашивал, как ему теперь данные восстановить. Много лет занимался разработками (инженер, как я понял), имеет патенты на изобретения, много секретной информации, за десяток (а то и не один) лет. Данные хранил на флешке и больше нигде...
Bootmen
01.04.2024 18:16Я как то восстановил флешку. Нашел какойто прибамбас в Инете и починил.
Правда флешка после определялась системой как неизвестная фирма.
Bootmen
01.04.2024 18:16Лет так 15 назад домашние фотки бэкапил на DVD. Причем фотки жал
в формат .jp2 (чтоб места занимали без потери качества) Счас конечно нафотаное
непосильным трудом умещается только на флешках 128 гг. Благо недорогие.
На работе серверов немного. Но все в основном с зеркальным раидом.
Раз в неделю выдергиваю диск, подписываю, ложу на полку. В сервер вставляю
чистый и DD и далее ресинхронизация. Вот такой у меня бекап. :)
Кстати все сервера в нашем учреждении имеют резервные сервера.
Резервный сервер ничего не делает, только принимает данные от основного
сервера. В случае падения основного сервера, нужно оператору переключится
на резерв. И он продолжит работу с того места где кончился основной сервер.
И присвоит себе его IP
DaemonGloom
01.04.2024 18:16Раз в неделю выдергиваю диск, подписываю, ложу на полку. В сервер вставляю чистый и DD и далее ресинхронизация.
А в сервере нет места под третий диск? Просто более разумно будет "вставить третий, сделать тройное зеркало, после успеха - достать старый". Если в момент ребилда по вашей схеме у вас умрёт диск - будет неловко.
eugeneb0
01.04.2024 18:16+1В далёком 97-м году друг рассказал печальную историю о полетевшем диске, в результате чего все его файлы остались "как бы на месте", но... заполнились нулями.
Поэтому, когда я написал бэкап для себя, я вставил в него простую штуку. При копировании, если основной и запасной файл заявляют себя одинаковыми, я с вероятностью, скажем, в 1% всё равно сравниваю их хэши. С тем, что если диск начнёт сыпаться, то проблема поймается эдак на сотом потерянном файле. А не на стотысячном.
И эта проверка обнаруживала иногда интересные эффекты. Например, как Винда копирует гигабайтный файл по сети? Она узнаёт его размер. Потом создаёт на "той" машине пустой файл размером в 1 гигабайт. С тем же названием и атрибутами, что и оригинал. И потом в него пишет байты. Что случится, если в этот момент сетка вдруг порвётся? Правильно. Половина файла случится.
Терял ли я сам файлы? Редко. Следите за руками:
С крошечной вероятностью можно случайно ткнуть в Shift+Del, затем Enter на клавиатуре.
На другой день файл стирается из бэкапа. Но его предыдущая версия там пока сохраняется.
Проходит много лет.
Диск для бэкапа переполняется, и я покупаю новый.
На который, естественно, я пишу оригиналы файлов, а не копию копий со старого бэкапа.
Из-за чего старая версия улетает в мусорку...
Ещё через пару лет я спохватываюсь: вот здесь же был мой файл!
mayorovp
01.04.2024 18:16Например, как Винда копирует гигабайтный файл по сети? Она узнаёт его размер. Потом создаёт на "той" машине пустой файл размером в 1 гигабайт. С тем же названием и атрибутами, что и оригинал. И потом в него пишет байты.
Это не только Винда так файлы копирует, это в принципе единственный правильный способ записи на диск файлов заранее известного размера.
Mike-M
01.04.2024 18:16В голосовании отметил первую историю, но понравились и другие: 1, 8, 10, 12, 13, 14, 15.
На работе всегда делал бэкапы. Но они ни разу не понадобились. Вывод: бэкап – это как страховка; если её не имеешь, то по закону подлости она обязательно понадобится.
werter_l
01.04.2024 18:16Kopia для файлов\папок (умеет шифровать данные и в S3).
Proxmox backup server для ВМ\lxc (умеет бэкапить инкрементно и проверять(!) бэкапы).
Truenas scale как nas (есть возможность создания снепшотов датасетов по расписанию).
P.s. Появилась возможность легкой миграции с vmware esxi на proxmox ve - https://forum.proxmox.com/threads/new-import-wizard-available-for-migrating-vmware-esxi-based-virtual-machines.144023/
P.p.s. Заметки по работе с proxmox, zfs, pfsense etc - https://forum.netgate.com/topic/163435/proxmox-ceph-zfs-pfsense-и-все-все-все-часть-2/
larteezy
01.04.2024 18:16А почему в первой истории просто не копировать только новые фотографии? Так ведь и быстрее будет и все остальные фото останутся в первоначальном виде, то есть не заменятся на повреждённые
AndronNSK
Однажды админ заказчика позвонил нам, исполнителям, и спросил "а как восстановить базу из бэкапа, если бэкапа нет?"
А был там sql server и в нём чтобы настроить бэкап нужно было 2 какие-то вещи сделать. Админ сделал только одну)
Давно это было) лет 15 назад)
mayorovp
Это какие 2 вещи-то? Создать бэкап и перенести его в отдельное хранилище бэкапов?
Так это не только в sql server так работает...
Pochemuk
Например, сделать план обслуживания на создание резервной копии. Но не сделать расписание его запуска :D