1 апреля — о серьёзном: факапы бэкапов

Однажды админ заказчика позвонил нам, исполнителям, и спросил "а как восстановить базу из бэкапа, если бэкапа нет?"

А был там sql server и в нём чтобы настроить бэкап нужно было 2 какие-то вещи сделать. Админ сделал только одну)

Давно это было) лет 15 назад)

- Я случайно базу данных. К счастью, я сделал скриншот.
- Снапшот?
- Нет.

Это что за чудесная система такая, что ошибка в редакторе PDF приводит к битым секторам на диске? DOS?

15. Исчезновение одной виртуальной жизни

Ну у себя-то на диске нужно было оригиналы хранить! Этот VK же пережимает небось всё под свои форматы в любом случае.

8. Художника обидеть может каждый

Тут вообще вопрос потери был просто вопросом времени, мне кажется. Рано или поздно телефон либо утонул бы, либо отказался бы включаться, либо его украли бы. А то, что он сам сбросился до заводских настроек - это всего лишь один из возможных сценариев.

Вывод напрашивается неутешительный: или каждый раз перед копированием проверять на работоспособность все тысячи файлов, или каждую резервную копию записывать вместе со старой, а не вместо её.

Вариант решения - бэкап должен обладать свойством самопроверки, а еще лучше - самовосстановления. Я тоже бэкаплю тысячи фоток, но после формирования пакета натравливаю на него MultiPAR (ранее QuickPAR). В итоге пакет можно быстро проверить на целостность, и в случае выявления небольшого повреждения - восстановить.

В один день мой телефон сбросился до заводских настроек САМ ПО СЕБЕ (спасибо, китайский поко), удалив абсолютно всё, над чем я годы трудился…

Буквально пару дней назад звонит сестра, айфон ночью засветился, выключился, и больше не загружался, вис на яблоке. Допрос с пристрастием привел к версии - место в хранилище практически закончилось (привет картинкам WA, telegram и т.д.), айфон на это ругался, но попытался поставить обновление и место закончилось совсем. Запуститься уже не смог, попытки недеструктивно восстановить систему ни к чему не привели, пришлось прошивать через DFU, с потерей всех данных. Бэкапа образа телефона не было, iCloud тоже был забит всякой мутью, вместо критичных данных.

"Ну я же тебе говорил, что нужно" "А у меня на ноутбуке места тоже нет".

Да, на ноутбуке у нее оказалось свободно 4 ГБ диска, все забито фотками и видео, опаньки, ждем следующий факап. :(

Мир стал сложнее. В части бэкапов администраторы теперь делятся на заметно большее количество категорий:

Кто не делает бэкапы

Кто стал делать бэкапы

Кто стал регулярно делать бэкапы

Кто стал регулярно делать бэкапы в разные целевые ресурсы разных типов (на локальные и сетевые носители (разных типов, производителей, моделей), в облачные хранилища)

Кто стал регулярно делать вышеуказанное как минимум двумя разными инструментами (разных поставщиков систем резервного копирования (СРК)), или, по возможности, в стандартизированные форматы резервных копий

Кто в дополнение к вышеуказанному стал регулярно проверять и свежие и, с меньшей интенсивностью, исторические, бэкапы (а то всё было хорошо, но вдруг обновлённая СРК разучилась понимать свои же форматы N-летней давности; в этом же контексте – кто сохраняет установочные пакеты предыдущих версий СРК)

Кто стал перепроверять бэкапы, как указано выше, сторонними совместимыми средствами (а не только средствами самих систем резервного копирования – самопроверка это хорошо, но альтернативная проверка не помешает)

Кто, в дополнение к вышеизложенному, стал не только проверять бэкапы, но и регулярно (периодически?) проводить «учения» по восстановлению данных из бэкапов, со сверкой восстановленных данных, полученных из не менее чем двух источников – например, на одну и туже дату-время резервирования, из двух разных СРК, или сверять ранее синхронизированные «замороженные» данные и данные, восстановленные из резервной копии.

Дорого? Ресурсоёмко? Спокойствие ценнее.

В серверной одного предприятия стояло две стойки с серверами. Нужно было обеспечить высокую надежность и доступность. Все работало - резервировалось, балансировалось, делались бекапы на сервера-хранилища с рейдами (в те времена еще облачные сервисы не были развиты). Все это хозяйство запитывалось через мощный бесперебойник, способный держать электропитание в течение как минимум 40 минут пока резервный генератор не запустится при необходимости. В общем почти все по фен-шую...
И вот эта вся надежность сыграла злую шутку. Глубокой ночью прорвало воду на техническом этаже, и вода потекла водопадом на серверные стойки. Охранник понимает всю серьезность ситуации и обесточивает серверную. Но бесперебойник продолжает работать, вентиляторы на серверах затягивают воду внутрь и щедро орошают всю электронику внутри корпусов...
Сервера начинают выходить из строя один за другим. Выходят из строя и сервера с бекапами... Бесперебойник держится до конца, пока поднявшаяся вода не зальет управляющую плату и он сам тоже не выйдет из строя...
Наутро аврал с полным разбором всех серверов, промывкой плат спиртом для вытеснения воды, сушка и сборка. Восстановление работоспособности. На удивление - порядка 75% парка серверов тогда восстановить удалось...

Последнюю историю ИИ писал?

Нас лет 8 назад взломали по RDP. Аккаунт был практически не рабочим, поэтому ничего там особого не пострадало. Но злоумышленник запустил на этом аккаунте скрипт, который находил в сети все доступные шары и шифровал их содержимое.

Среди этих доступных этому аккаунту шар оказался диск на одном АРМ SCADA-системы, на котором находился рабочий SCADA-проект. По недосмотру дали к нему временно общий доступ для удобства настройки, а потом снять разрешения забыли (это был я, если что). SCADA зависла и больше не запускалась, разумеется.

Когда посреди ночи локализовали и нейтрализовали угрозу, встал вопрос о восстановлении проекта из резервных копий. Но оказалось, что инженер, создававший эти проекты, хранил их в разделе файлопомойки с общим допуском, а не с ограниченным личным или отдельским. Разумеется, зловредный скрипт тоже обнаружил эту доступную ему шару и зашифровал в ней всё.

Хорошо, что у этого инженера на компе сохранился проект двухмесячной давности. Запустили его. А этот товарищ две недели спешно восстанавливал нововведения за этот срок.

Так что, резервные копии не только должны быть, но и надежно храниться. Желательно, в разных местах.

Когда занимался ремонтом мобильной техники, то часто приносили убитые вусмерть телефоны с просьбой вытащить информацию (в основном фотографии). Некоторые получалось частично оживлять для восстановления инфы, но подавляющее большинство не восстановимо. Приходилось объяснять людям, что если нет бэкапа - значит данная информация для них не столь важна что ее можно потерять.

Статья -- бэкап факапов :)

а как же cfdisk, которые ломает структуру файловой системы?
я один споткнулся на этом, когда только знакомился с линуксом?

Приняли стажера, а в качестве ментора поставили джуна, который сам вчерашний студент. Стажеру дали небольшую задачу для ознакомления, и он захотел тестовый сервак для погонять. Джун ему и выделил как бы ненужный сервер, для опытов. А это оказался клон сервера с данными для аналитиков. И когда у них что-то полетело на основном, они побежали на клон, а там вместо нормальных данных - кракозябры, пустые строки и матюки.

Так я в первый раз отучился матюкаться в тестовых данных.

Ничего не написали про главный backup - про дублёров ключевых сотрудников. А без них и резервные копии не резервные копии, если в них никто не сможет разобраться.

Мне сразу вспомнилась история пиксар, как у них накрылся основной сервак, на котором все материалы по истории игрушек были и повезло, что одна из дамочек работала из дома и у нее была локальная копия относительно свежая.

Прошлым летом NAS начал кричать уведомлениями, что один из жёстких дисков находится к критичном состоянии.

Бюджетная организация, денег традиционно нет. Спонсоров летом не найти, они лишь к концу года появляются.

К новому году сетевой диск перестал быть доступным, результат работы десятков людей за многие годы просто исчез. За восстановление данных платить опять некому. Да и не обещают ничего...

Вот так и живём...

Однажды в нашей тесной конторке программистов раздалось сочное "Б#%π§ть!", за столом ведущего программиста, к нему тут же подскочил начальник и повторил то сочное слово. Оказалось, что ведущий программист разбирал код какого-то запроса в Query Analyser, выделил фрагмент и случайно нажал кнопку "выполнить". Query Analyser и выполнил, именно выделенный фрагмент, где был запрос delete from <table>, но без условия, которое выделено не было... База оказалась рабочей, а не тестовой.

Я тогда был стажёром на испытательном сроке, спросил, что случилось, мне объяснили и я проникся. Но по счастливой случайности я всех спас тем, что у меня случайно оказался свежайший бекап именно той таблицы. У меня было задание сделать утилиту для работы с dbf файлами (были отделы с софтом на foxpro) и написание этой нудятины скинули на меня, утилита должна была провести манипуляции с dbf файлом, сделать пару отчётов и упаковать все в архив. И чудом именно в то утро я слил именно пострадавшую таблицу в dbf формат (там были все нужные мне типы данных), чтобы локально тихонечко пилить свою утилиту и мучать эту dbf-ку.

По "6. Лёгкий 1С-ный испуг" добавлю (по памяти), если кому интересно, что не всё прошло "без сучка и задоринки". OLE имело свои ограничения, в частности целые числа там всегда передавались как вещественные, а число 0 в заготовке обработки, которую взял за основу, просто игнорировалось, насколько помню. В результате, в спецификациях "весело" было наблюдать вместо нулей NULL, или "Неопределено" (1С тут имеет несколько вариантов, вроде), не помню уж теперь. Но к счастью логику работы это не поломало. И ещё добавлю несколько слов. Люди работали, пока я готовился к ремонту. Они могли несколько раз исправить документы прошлого месяца, исправлять справочники и даже что-то удалить. Задача была, чтобы это всё учесть. Готовился интенсивно дней 5-6, вроде, судя по сохранившимся копиям версий обработки, а потом тренировался, контролируя вновь поступившие данные. Но сначала нужно было определить, когда возникла проблема и в чём заключалась. Вот для этого пришлось многократно разворачивать имеющиеся копии и сравнивать в них отчёты, а потом анализировать журнал регистрации. Именно по журналу регистрации (обычный текстовый файл, за исключением кодировки объектов), и удалось всё восстановить. Перенести его часть после исходного бэкапа в отремонтированную базу потом не представлялось возможным (условно идентификаторы объектов поменялись). Жалоб не поступало, хотя понимаю, что это не показатель. Но выборочная проверка дала некоторую долю уверенности. Изначально этот пост опубликовал у себя на Дзене.

Не совсем в тему, но хочу поделиться. У меня с бекапом была одна счастливая (в целом) история.

Для подготовки обновления потребовалась база от Заказчика. Размер бекапа 4 ГБ, а в упакованом виде сильно меньше, поэтому файл хранился в архиве. Распаковал и запустил восстановление, но SQL Server выдал ошибку. А базу эту я уже восстанавливал когда-то. Удивился, распаковал ещё раз и опять ошибка при восстановлении. Тут уж я испытал когнитивный диссонанс.

Как же так - я же точно помню, что успешно восстанавливал базу из этого архива! Или всё-таки не из этого архива? Может перепутал? Может 7-zip обновился и по другому распаковывает? Или Каспер проверяет на лету и курочит?

В конце концов решил сравнить контрольные суммы файла в архиве и распакованного. И вот тут я узрел чудо - контрольные суммы были разные. Распаковал ещё раз в другое место - контрольные суммы сошлись. В общем, жёсткий диск начал сыпаться и выдавал подобные чудеса.

К счастью, всё обошлось. Винт заменили и вроде больше ничего не сломалось. Но админ, ответственный за оборудование, поверил в это не сразу. Пришлось делать скриншоты контрольных суммм.

Где-то году в 2010 была история. Как-то 28 декабря в последний рабочий день зашли в серверную ПРОСТО ПОСМОТРЕТЬ. Нужно было составить схему сети и для этого посмотреть коммутацию. Ничего даже не трогали, просто открыли дверь шкафа, а из-за плохо вставленного в один из двух блоков питания СХД кабеля контакты заискрили и одна полка отвалилась, несмотря на второй БП. СХД IBM DS4700. Бэкапа почему-то не было, по-моему незадолго до этого сервер бэкапов вышел из строя и мы ждали оборудование на замену.

После перезагрузки СХД массив не поднялся,из интерфейса тоже никак не поднимался.

Было потрачено много нервов, по дружбе один из интеграторов прислал специалиста по СХД IBM, но он тоже разводил руками.

На СХД вся жизнь компании. В итоге уже ближе к ночи, в cli пробую какую-то команду и система поднялась. Я был счастлив. Причём команда какая-то очень простая, которая просто LUN делает online.

Дааа, была у меня история. Я школьник 15 лет, учусь на программиста сам. Около полутора лет пользуюсь Федорой. И после перехода на Линукс я очень много раз стрелял себе в ногу) Первый раз был после первой установки, когда я выделил 50 Гб места на всю систему, а потом до меня дошло, что маловато будет. У меня был дуалбут, поэтому я просто зашёл в Винду, открыл средство разметки дисков и отформатировать раздел, где был Линукс) В итоге загрузчик сломался, починить так и не смог, поэтому Винду пришлось переустановить тоже.

Второй случай был совсем недавно. Я уже почти полностью пересел на Линукс, Винду включал редко. Но на виндовском диске с ntfs были мои старые проекты, которые мне захотелось перенести на другой диск, уже с btrfs. Скачал драйвер, подмонтировал диск, а он read only. Мог бы скопировать всё, что нужно и потом забить, но я решил разобраться. Раньше же работало. Погуглив, выяснил, что из-за сетевой папки, которую я на этом диске настраивал на винде, файловая система находится в заблокированном состоянии. Для того, чтобы это состояние снять, можно было перезагрузиться, зайти в Винду, снести общий доступ, перезагрузиться и работать дальше. Или просто выполнить команду, которая за меня все сотрёт. Само собой, я начал искать эту команду. Открыл stackoverflow и случайно скопировал команду из вопроса, а не из ответа. Этой командой была wipefs... После перезагрузки ничего не загружалось. Беру livecd, пытаюсь починить, восстановил. Было страшно)

Самое фееричное было буквально две недели назад. Я использую timeshift для бекапов, узнал о нем из видео на Ютубе в духе "топ 10 обязательных программ для Линукса". Скачал, изучил, настроил бекапы каждый Бут, каждые пару дней, а раз в месяц полный, и счастливо забил. А потом пытался сделать второй монитор через xrandr, и сломал все. Судя по логам, dbus перестал загружаться вообще. Способа починить не нашел. Вспоминаю про бекапы, беру live cd, бекап на месте. Моему счастью нет предела, нажимаю кнопку восстановления и "ваша фс не соответствует формату бекапа, восстановление невозможно". Оказалось, для работы timeshift в btrfs должны быть сделаны partitions с названиями @home, @root и тп. В общем, схема для Ubuntu, как выяснилось позже. Само собой, при установке системы я этого не сделал, поэтому плакал мой бекап. А проверять восстановляемлсть мне мозгов не хватило)

Все закончилось хорошо, я купил ssd на террабайт, поставил туда свежую систему, уже правильно, а тот диск смонтировал и переносил нужные программы и данные по крупице через far) восстановил все, что нужно было, но опыт полезный конечно.

Думаю как-нибудь сделать из этих историй статью.

Когда-нибудь ты станешь немощен и слаб

Делай бекап, давай, делай бекап....

нет бэкапа - нет бэкапа.

Ситуацию наблюдал университете, в далёком 2001 году:

Студент делал большую курсовую работу в "компьютерном центре" электротехнического факультета. Долго делал, наверное месяц. Когда пришла пора распечатывать курсовую, выяснилось, что дискета не читается... Самый большой шок нас ожидал когда выяснилось что второго экземпляра нигде нет: он всегда его редактировал прямо на дискете...

Другой дискеты у него просто не было, нигде на компьютерах не сохранял... Ему просто никогда не объясняли как надо делать правильно.

Кажется часто корень проблем с бэкапами кроется в этом: люди принимающие решения просто не представляют что это и зачем. Им обязательно надо всё подробно объяснять - "обозначать риски".

Лет так 15 назад домашние фотки бэкапил на DVD. Причем фотки жал

в формат .jp2 (чтоб места занимали без потери качества) Счас конечно нафотаное

непосильным трудом умещается только на флешках 128 гг. Благо недорогие.

На работе серверов немного. Но все в основном с зеркальным раидом.

Раз в неделю выдергиваю диск, подписываю, ложу на полку. В сервер вставляю

чистый и DD и далее ресинхронизация. Вот такой у меня бекап. :)

Кстати все сервера в нашем учреждении имеют резервные сервера.

Резервный сервер ничего не делает, только принимает данные от основного

сервера. В случае падения основного сервера, нужно оператору переключится

на резерв. И он продолжит работу с того места где кончился основной сервер.

И присвоит себе его IP

В далёком 97-м году друг рассказал печальную историю о полетевшем диске, в результате чего все его файлы остались "как бы на месте", но... заполнились нулями.

Поэтому, когда я написал бэкап для себя, я вставил в него простую штуку. При копировании, если основной и запасной файл заявляют себя одинаковыми, я с вероятностью, скажем, в 1% всё равно сравниваю их хэши. С тем, что если диск начнёт сыпаться, то проблема поймается эдак на сотом потерянном файле. А не на стотысячном.

И эта проверка обнаруживала иногда интересные эффекты. Например, как Винда копирует гигабайтный файл по сети? Она узнаёт его размер. Потом создаёт на "той" машине пустой файл размером в 1 гигабайт. С тем же названием и атрибутами, что и оригинал. И потом в него пишет байты. Что случится, если в этот момент сетка вдруг порвётся? Правильно. Половина файла случится.

Терял ли я сам файлы? Редко. Следите за руками:

1. С крошечной вероятностью можно случайно ткнуть в Shift+Del, затем Enter на клавиатуре.

2. На другой день файл стирается из бэкапа. Но его предыдущая версия там пока сохраняется.

3. Проходит много лет.

4. Диск для бэкапа переполняется, и я покупаю новый.

5. На который, естественно, я пишу оригиналы файлов, а не копию копий со старого бэкапа.

6. Из-за чего старая версия улетает в мусорку...

7. Ещё через пару лет я спохватываюсь: вот здесь же был мой файл!

В голосовании отметил первую историю, но понравились и другие: 1, 8, 10, 12, 13, 14, 15.

На работе всегда делал бэкапы. Но они ни разу не понадобились. Вывод: бэкап – это как страховка; если её не имеешь, то по закону подлости она обязательно понадобится.

Kopia для файлов\папок (умеет шифровать данные и в 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/

А почему в первой истории просто не копировать только новые фотографии? Так ведь и быстрее будет и все остальные фото останутся в первоначальном виде, то есть не заменятся на повреждённые