Как стать автором
Обновить

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

Уровень сложностиПростой
Время на прочтение10 мин
Количество просмотров13K
Всего голосов 46: ↑45 и ↓1+63
Комментарии80

Комментарии 80

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

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

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

Это какие 2 вещи-то? Создать бэкап и перенести его в отдельное хранилище бэкапов?

Так это не только в sql server так работает...

Например, сделать план обслуживания на создание резервной копии. Но не сделать расписание его запуска :D

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

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

"Как хранить данные в png, не привлекая внимания санитаров" https://habr.com/ru/articles/590469/

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

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

могу тоже самое сказать про разработку на windows :)

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

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

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

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

При том, что в телефоне зачастую есть облако от Google

облако от Google

Бесплатное, места в котором всё-равно не хватает через несколько недель рисования.

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

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

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

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

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

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

Да. Вы знаете, что такое фото рабство? Когда девушка просит сфоткать ее. И не нравится. Ещё и ещё... Сотни фоток...

И так до следующего краха жесткого диска? Ведь сортировать всё это, записывать на внешние носители для резерва никто не будет.

Отчитаюсь, в подарок взят WD Blue 2TB и внешний боксик, глядишь - будет туда сбрасывать все ценное..
Проверил, скорость хорошая, работает устойчиво ;)
Проверил, скорость хорошая, работает устойчиво ;)

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

+1 за MultiPar, тоже недавно открыл его и пользуюсь с удовольствием. У этой утилиты небольшая огласка, и мало кто про нее знает, хотя на практике она очень удобна. Ближайшее что есть по функционалу - информация для восстановления в winrar, по степени удобства сильно позади.

Только в описанной ситуации думаю мультипар бы не помог. Насколько я понял из описания, у него была полная и постоянно пополняемая коллекция фоток на основном диске, и регулярно делался ее бэкап на внешник. В какой-то момент основной диск стал сыпаться (или ещё как-то побились файлы), и часть фоток стали битыми. Очередной бэкап был сделан уже с битой инфой, а старый (с нормальной) удален для экономии места. И думаю прошло немало итераций таких бэкапов, прежде чем повреждения обнаружились. Здесь могло бы помочь только хранение очень старых версий бэкапов, или какое-то сравнение бэкапа не только с источником, но и со старым бэкапом (и то, настраивать надо было отдельно, т.к. это не отличить от замены файлов просто новой версией). В общем, трудноуловимая ситуация на самом деле. Если это реально произошло из-за того что диск посыпался - можно было отследить по статусу SMART (регулярно его проверяю для своих дисков). А если какая-то сторонняя прога, кривой скрипт или что-то ещё побило файлы, то практически никак.

Я держу два диска с холодным архивом фоток, и свежие не сортированные отдельно. Свежие бэкапятся еженедельно ещё в два места, перед переносом в архив считается CRC, ежегодно проверяется CRC на архивных дисках. Архивы лежат физически в разных местах.

Пока потерь нет.

Можете подсказать не очень знающему человеку: я пользуюсь FreeFileSync для инкрементного копирования некоторых данных с домашнего ПК на внешний жесткий диск. Там перед "зеркалированием" сначала проводится анализ файлов с обоих сторон, потом копируются/заменяются новые/обновленные файлы.
Если все файлы изначально были целы и программа решила что и её бэкап - идентичный - это ведь значит что файл не может быть битым? Просто у меня там тысячи папок и десятки тысяч файлов - проверять их все, очевидно, невозможно.
Могу ли я как-то улучшить/обезопасить процесс бэкапа?

А разве не помогло бы просто бекапить только новые фото, не трогая старые? Ведь проблема в том, что похоже все перезаписывалось, и однажды целое - стало битым на основном жд и с него уже была сделана битая копия.

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

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

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

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

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

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

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

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

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

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

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

Был у меня заказчик, который сказал - хочу волшебную кнопку EPO от APC :) Вот она бы точно помогла вашему охраннику (для этого и придумана).

Была похожая история с затоплением серверов. Центр Москвы, в подвальном помещении бордель для элитных господ (формально - отель), а в бизнес центре как внезапно выяснилось, организовали банно-прачечный комбинат. С гастарбайтерами и соответствующей спецификой. Ровно над серверной. По классике жанра протечка случилась ночью, уничтожение железа 90% Диски умерли все. Сильно помог офлайн бэкап "в сейф" в соседней комнате.
А владелец бизнес центра, после нашей просьбы о компенсации ущерба демонстративно сказал, показав в смартфоне свое фото с Аркадием Дворковичем (бывшим тогда гдет в правительственных кругах важной персоной), - "можете со мной судиться, но шансов у вас нет". Взвесив факты и шансы, вскоре съехали оттуда.

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

В наше время - не исключено ;-)

"Без момента колебаний", "Это был жаркий день... часы напряжённого труда... к полудню удалось восстановить"

-- не, ИИ и языком получше владеет, и временнОй логикой.

Зато какой полёт фантазии!!!

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

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

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

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

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

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

Ну, для файлов это само собой.

Но теперь объясните как настроить архивацию сегментов wal в подобном режиме...

Как хотите, но должна быть хотя бы одна копия, недоступная из сети. Как в комментарии ниже, например. Как известно, информация делится на сохраненную в оффлайне и потерянную

Мастер сервер кладет файлы в каталог в локальный каталог archive.

Реплика забирает файлы с мастера и удаляет их, например rsync --remove-source-files
Или мастер по расписанию сам удаляет файлы старше N-часов из archive.

У нас сейчас так копии БД снимаются.

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

Но всё равно существует временной зазор, в течение которого возможна порча бэкапов.

В идеале, при бэкапах должна на лету подсчитываться контрольная сумма и каким-то образом передаваться конечному хранилищу для контроля неизменности. При несовпадении - алерт. Но в SQL такого нет, а подсчитывать КС уже после завершения создания резервной копии - уже нет смысла.

Рядом с бэкап-сервером ставится SQL-сервер, на котором тестируется восстановление из бэкапа, с письмом о результате.

О! Нашел демотиватор, который сделал после того случая. На картинке почти что я (слева) с тем инженером (справа):

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

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

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

можно подробнее?

ставите допустим новую систему рядом со старой

вот пришло время создавать разделы. Ставим, конечно, archlinux (btw), поэтому никакого гуи у нас нет. Тут у вас несколько вариантов sfdisk, cfdisk, parted.

Самый интуитивный, я полагаю, cfdisk, так как он имеет tui интерфейс.

Заходите в него. Уменьшаете размер раздела, на котором у вас стоит /home допустим от первой системы, чтобы выделить место под новую систему. В итоге файловая система уменьшенного раздела повреждена...

Следующие 8 часов вы проведете за поиском способа для восстановления.

И, если вы неопытный новичок(коим я и был), сдадитесь, попращавшись со всеми вашими очень и не очень важными данными.

Возможно я тут ошибаюсь насчет cfdisk и это я где-то накосячил, но я уже и раньше слышал от других людей об этой проблеме.

GParted с этим легко справляется. Т.к. он использует libparted, то и parted полагаю тоже.

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

Правильный метод - resize2fs на нужный раздел с указанием нового размера чуть меньше желаемого, потом уменьшение раздела через любой менеджер, затем снова resize2fs для точного выравнивания конца файловой системы по концу раздела.

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

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

Было бы лучше, если бы аналитики увидели совершенно нормальные, только ложные, данные?

Не в тему, но по поводу стажеров ...

Тут на днях приходил пацанчик устраиваться. С мамашей. А нач отдела - любитель байков. И у него на стене висит календарь с голой бабой на мотоцикле. Ну не совсем голой - в шлеме.

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

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

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

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

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

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

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

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

Внезапный Deus ex machina :)

По "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) восстановил все, что нужно было, но опыт полезный конечно.

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

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

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

Делай. Для ИИ несложно.

? Не совсем вас понял

Как говорил один анимешный персонаж: "Опыт приходит с болью".

Со временем боли становится меньше ... впрочем, есть те, которым она, наверное, нравится :D

Боли становится меньше, но количество способов все сломать каждый раз меня поражает) Ходя удивляться, в прочем, нечему. Сам выбираешь свой путь. Ну я и выбрал, и мне даже нравится. Главное не потерять данные, а фиксы таких проблем - занятие очень даже интересное. Пока разбирался, почитал здесь же про устройство btrfs, cow механизм, systemd, устройство dbus, файловые системы. Накапливается своего рода база ошибок, с которыми потом проще справиться в разы самому или подсказать другому, если вдруг похожая проблема

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

Сильно

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

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

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

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

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

Я как то восстановил флешку. Нашел какойто прибамбас в Инете и починил.

Правда флешка после определялась системой как неизвестная фирма.

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

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

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

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

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

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

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

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

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

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

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

только на флешках 128 гг

Со стеканием заряда бороться не забываете, надеемся?

А бывает что то вечное?

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

А в сервере нет места под третий диск? Просто более разумно будет "вставить третий, сделать тройное зеркало, после успеха - достать старый". Если в момент ребилда по вашей схеме у вас умрёт диск - будет неловко.

Не умрет. Есть сервер ждет.

Знаю md

Места нет

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

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

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

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

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

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

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

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

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

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

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

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

Это не только Винда так файлы копирует, это в принципе единственный правильный способ записи на диск файлов заранее известного размера.

В голосовании отметил первую историю, но понравились и другие: 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/

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

Обычно так происходит, потому что для копирования только новых нужно разбираться с каким-то отдельным софтом, а копирование всего подряд - это банальный copy-paste.

Например, лично я использую rsync с тщательно подобранными ключиками, но вот как жить обычному пользователю - страшно представить.

Просто нажимать "пропустить всё" в диалоге копирования?

Ну, кстати, да. В общем случае, для документов каких-нибудь, не прокатит. Но изначально речь шла про фоточки, а для них - прокатит вполне.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий