Комментарии 15
Бэкап - лучшее снотворное ;) Когда я был студентом и подрабатывал сисадминством, в одной конторе был очень экономный владелец - даже на ПК, назначенном сервером, у него работал сотрудник. Об отдельной машине для бэкапов не было и речи, а про СХД/NAS тогда и не знали особо в малом бизнесе (1999 год). У меня тогда была практика, хоть как-то, но бэкап делать.
В итоге сервер всё равно бэкапился по сети на другую пользовательскую машину с винчестером побольше. А там работал нехитрый скрипт, подчищающий бэкапы - неделю хранились ежедневные инкрементальные, потом в выходной делался недельный бэкап + ежегодно делался еще один, неудаляемый.
В итоге, когда я уже там не работал года четыре - этот владелец позвонил, и спросил - кто занимается восстановлением данных. Диск на "сервере" всё-таки накрылся. И да, хэппи энд, машина пользователя уцелела и исправно сохранила бэкапы. А за пароль от архивов получил ящик пива ;)
Мы же в текст добавили истории клиентов Selectel, которые подключили услугу автоматических бэкапов по расписанию в облачной платформе.
Поучительные байки в треде приветствуются!
Когда-то я пробовал недорогой хостинг, который предлагал за отдельные небольшие деньги забэкапить сервера аж в другом их датацентре. И в один "прекрасный" день они случайно все сервера и все бэкапы. Какие-то проблемы с Ceph, вроде бы. Забавно выглядели их письма с извинениями, в каждом следующем письме добавлялось орфографических ошибок, тон становился всё более нервным, и потом они окончательно разорились и исчезли. Хорошо, что у меня не было необходимости бэкапить данные!
Кстати, да, есть и такие истории( К сожалению, не всем провайдерам стоит доверять свои бэкапы. Только ооочень надежным, да и то все равно лучше подстраховаться холодной копией. Радует, что вы не стали жертвой!
Недорогой хостинг звали cloudmouse и, помнится, системных администраторов у них как раз не было.
Делал всегда бэкап на отдельный сервак + переносной HDD. Не раз спасало.
Вариант супер — две реплики всегда лучше одной. А руками делали или автоматизировали?
Руками, т.к. HDD сам лично подключал, копировал, смотрел, что копировать. Базы делали бэкапы, их сам тоже переносил. В принципе да долго, но зато с гарантией и эта гарантия меня не раз выручала. Да ПК было всего 25, если было бы штук 200, тогда конечно делал бы все по-другому. А самое классное, меня это спасло от шифровальщика ))) Я просто все восстановил, быза пострадали суточные, а остальные данные недельные - край 2-х недельные.
Сталкивался со случаем, когда люди делали вручную копии базы 1С (тогда была семёрка), вроде даже ежедневно, однажды база упала, они сделали резервную копию, попытались использовать штатную функцию тестирования и исправления базы, это не помогло, а вот с резервной копией потом выяснилось, что они всегда делали выгрузку в один и тот же файл, затирая предыдущую версию...
А я 22 года назад восстановил бэкап БД MS SQL не в отдельную среду (нужна была копия системы то ли для проверки чего-то, то ли для долгого отчета), а на её старое место. Меня, конечно, спасли резервные копии журналов транзакций (и то, что они делались, и то, что я вообще знал, что это такое), но "упс" был тот еще.
Короче, мораль: операции восстановления проводить вдвоём, перепроверяя друг друга, аккуратно и предприняв действия, чтобы не сделать хуже.
Ключевой маркер хорошего бэкапа - регулярные тестовые восстановления с подробным планом восстановления.
Т.е. раз в полгода минимум поднимается тестовая среда, аналогичная основной, берутся реальные ленточки/бэкапы и разворачиваются по инструкции (которая написана так, чтобы студент мог последовательно исполнить, ну или любой инженер спросонья после бурной ночи) с обязательным включением методики проверки успешности поднятия сервисов. Любые нестыковки сразу исправляются и фиксируются. Практика показывает, что первый подобный процесс достаточно трудоемкий и часто не срабатывает, но последующие обеспечивают нужное спокойствие критическим сервисам.
Игра в «Было/ не было»: как делать бэкапы, чтобы не стать грустным админом