Как правильно сделать бэкап и избежать частых ошибок

Как сделать бэкап IMEI Android

IMEI, как нам известно, представляет собой уникальный номер идентификации смартфона. И достаточно часто случаются ситуации, когда этот номер необходимо сохранить, то есть, провести резервное копирование. Для этого будем использовать специальную программу Root Explorer. Для ее работы также необходимы root-права.

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

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

Не все бэкапы одинаково полезны

Создание резервной копии подразумевает, что в случае аварийной ситуации она будет работоспособной. Но, к сожалению, часто это не так. Резервная копия данных сама по себе не является гарантом их восстановления. Она может быть попросту непригодной для этого.

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

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

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

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

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

Также данным угрожает неправильный выбор средства резервного копирования. Например, когда администратор использует бэкап для виртуальной машины, на которой работает база данных, без поддержки целостности приложения (application aware backup).

Однако БД активно использует кэш в оперативной памяти, где и находится часть данных. СУБД записывает данные на диск, и они всегда согласованы между собой. При этом система бэкапа не учитывает синхронизацию кэша с файловой системой и записывает данные не мгновенно. Это приводит к тому, что при резервировании часть данных может быть записана в неправильном порядке, и когда ВМ восстановится — база будет повреждена.

Разработайте план по аварийному восстановлению

Системы резервного копирования, восстановления и репликации — важный элемент общего процесса непрерывности бизнеса, именно эти системы вернут к жизни компанию в случае сбоя. Однако самих систем недостаточно. У компании должен быть четкий план, что делать при потере данных или аварии.

План аварийного восстановления — документ, который содержит шаги по устранению последствий аварии и восстановлению данных; список ответственных сотрудников, их роли и обязанности; последовательность действий по защите и восстановлению IT-инфраструктуры.

Такой план включает в себя:

Выявление всех систем и типов данных, которые требуют бэкапа (на основе риск-анализа, о котором я уже сказал).
Разработка и выполнение процедур, которые гарантируют, что бэкап и планы переезда всех необходимых данных и систем выполняются регулярно. Насколько регулярно — выбор ИТ и собственников бизнеса.
Закрепление персональной ответственности за определенные аспекты реализации плана с учетом политики конфиденциальности.
Документирование действий в привязке к сервисам и ответственным за них в понятной и доступной форме.
Тестирование плана по аварийному восстановлению данных в действии.

Бэкап

Бэкап, он же резервное копирование – это создание снимков состояния разделов Windows, разделов или отдельных папок с нашими данными. Запечатлённая в снимках информация в будущем может быть восстановлена из этих снимков. Если что-то случается – например, Windows перестаёт корректно работать, вообще не загружается или теряется наша важная информация, мы просто восстанавливаем всё это из бэкапа.

У бэкапа есть слабые места:

• Плановое создание резервных копий нагружает систему. В лучшем случае системными фоновыми процессами, в худшем, когда хранилищем указан тот же диск, на котором установлена Windows – нагрузкой диска операцией записи;• Скопление резервных копий требует либо периодического нашего вмешательства для их удаления, либо использования функциональных программ-бэкаперов с возможностью применения схем автоматического удаления старых копий;• Родной механизм создания бэкапа Windows оставляет желать лучшего, а толковые программы-бэкаперы – это обычно платные сторонние продукты;• Если Windows перестанет загружаться, без ранее созданного Live-диска программы-бэкапера потребуется участие второго компьютера.

Некоторые из этих недостатков условны. Так, на сегодняшнем рынке софта представлено немало толкового ПО для резервного копирования Windows, которое в базовых бесплатных редакциях предлагает весь необходимый для обывательских нужд инструментарий. В числе таких программ, например, AOMEI Backupper и EaseUS Todo Backup. Штатный системный бэкап не имеет гибких настроек, его образы резервных копий занимают много места на диске, тем не менее это вполне рабочий механизм, который может восстановить Windows в случае её сбоя.

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

Защитите данные от вирусов-шифровальщиков (вымогательского ПО)

Согласно одному из исследований, объем атак вирусов-шифровальщиков, или, как их еще называют, вирусов-вымогателей, увеличился в 2019 году на 41% в сравнении с 2018 годом. И если вы думаете, что кибератаки касаются только крупного бизнеса, — это совсем не так. По оценкам ESET, в 2019 году 60% российских компаний в сегменте среднего и малого бизнеса пострадали от вредоносного ПО и 45% — конкретно от вируса-шифровальщика.

Лучшее средство от сбоя в системе безопасности — профилактика и меры предосторожности. Бэкапы на резервную площадку и на площадку без доступа к интернету не только минимизируют последствия вируса-вымогателя, но и в сочетании с надежным решением в области информационной безопасности и ИБ-тренингами среди сотрудников помогут предотвратить проблему в целом. . Существует целый ряд мер защиты данных

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

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

Как она работает?

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

На заметку. Для стабильной работы компьютера требуется, по меньшей мере, 10-15 % свободного пространства. Поэтому функция ТК нередко доставляет неудобства при эксплуатации устройства.

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

Как сделать бекап устройства Android через recovery

Теперь, во всеоружии мы подошли к основной части нашего разговора. Как должны выглядеть наши последующие действия.

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

Выбрав способ, который актуален для вашего устройства, открываем меню стокового рекавери. Мы увидим следующие пункты (все, частично или ещё какие-либо):

Reboot system now — перезагрузка смартфона.

Apply Update from SD-card – установка обновления с карты памяти.

Wipe Data / Factory reset – сброс системы до заводских настроек, или «вайп» (удаляются все персональные данные).

Wipe Cache Partition – очистка телефона от кэша.

Install zip from SD-card – устанавливание с карты памяти архива (обычно это официальное обновление).

Backup and restore – процедура резервного копирования и восстановления системы.

Кнопкой громкости перемещаемся по списку действий и выбираем «Backup user data» (на некоторых устройствах «backup and restore»), затем, нажав кнопку питания («Power») подтверждаем выбранное действие, после чего начнётся процесс копирования:

Резервная копия будет сохранена корневом каталоге на SD-карте.

Для восстановления данных снова нужно зайти в меню рекавери и выбрать пункт «restore user data», нажать «Power» из открывшегося списка сохранённых файлов, выбрать нужный, снова подтвердить выбор (кнопка питания — «Power»). Осталось перезагрузить устройство:

Видео по теме (Как сделать бэкап андроид через рекавери на примере Lenovo A850):

https://www.youtube.com/embed/%20″>

Как сделать бэкап IMEI Android

Первый день – пятница

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

Приезжаем на место (напомню, что сервер лёг и удалённого доступа нет), подключаемся с монитором и клавиатурой, ещё раз смотрим, как система не стартует.

Я подключился не сразу. Когда подключился — увидел, что диск переполнился ошибками из-за проблем бэкапа. Некоторые сервисы не стартовали — почистили логи, стартовали руками.

ОК, система запустилась, но только база пустая — данных никаких нет.

Уже дальше мы узнали и историю про юбилей, и про рестарт, и про всё остальное. Вообще-то для серверов такого класса нормально работать месяцами и годами без перерыва, но у Аваи есть регламент. Там в зависимости от нагрузки системы перезагрузка делается раз в 90 или раз в 180 дней. Очевидно, что регламент пять-шесть раз уже не соблюли. Это тоже нормально, до этого места инструкции дочитывают далеко не все, а если дочитывают, то считают, что это перестраховка вендора. Потому что это и есть перестраховка вендора.

Итак, у нас на руках — железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базой Informix от IBM + пакет CMS от вендора. Решение продаётся как программно-аппаратный комплекс, то есть всё там как поставил вендор, так никто и не трогал.

Бэкапы БД делались. Итерации были по 180 дней, бэкапирование настроено в планировщике системы. Логи бэкапов никто особо не читал, консистентность не проверяли, назад до этого юбилея сервака накатывать не пытались.

Складировались бэкапы прямо на этот же сервер.

То есть сначала уронили рестартом систему, ребутнули «с тележки» и поставили бэкап системы CMS, который уронил окончательно железный сервак. Мы починили сервак, но там не было вообще никаких полезных данных. Предстояли интересные выходные.

Как достичь максимума

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

Разработайте план по аварийному восстановлению

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

Используйте правило 3-2-1

3 копии данных — 2 независимых друг от друга носителя — 1 копия данных должна храниться в среде, не подключенной к основной инфраструктуре.

Соблюдайте требования регуляторов

Знайте, какими законами регламентируется хранение и управление данными клиентов вашей компании, и соответствуйте этим законам

Защитите данные от вирусов-шифровальщиков

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

Ключевое слово в резервном копировании и аварийном восстановлении — дисциплина

Помните, что компании сами в ответе за свои данные.

Всех с Днем бэкапа!

Проверка процессор на работоспособность с помощью тестового компьютера?

Варианты диагностики и устранения неисправностей:

Использование тестового компьютера.
Повторная установка процессора.
Программная диагностика.

Тестовый компьютер для проверки ЦПУ:

Как проверить кристалл процессор на исправность максимально эффективно?

Подключить его к тестовому компьютеру, чтобы с 99% уверенностью определить работоспособность ЦПУ.

Нужно учитывать, что другой компьютер должен иметь аппаратную совместимость с таким процессором.

Если после запуска проблема сохранится, то ЦПУ действительно является неисправным, а значит требует замены.

Строго не рекомендуется размещать чип тестового компьютера в своем системном блоке до выявления проблем, ведь это может привести к его непредвиденной поломке, так как слабым местом в состоянии оказаться, например, материнская плата, видеокарта или жесткий диск.

Повторный монтаж ЦПУ:

Еще одним вариантом является открытие крышки системного блока, чтобы сначала снять процессор, а затем повторно его установить.

Также необходимо отключить кабель питания. Требуется аккуратно и внимательно достать радиатор. Дальнейшие действия — извлечение процессора из самого сокета.

Если же никаких внешних дефектов не обнаружено, то стоит вновь осуществить монтаж с нанесением термопасты и надежным крепежом радиатора.

Также нужно убедиться, что все шнуры внутри системного блока качественно фиксируются на своих местах.

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

Диагностика при помощи специальных программ:

Эффективно выявляют различные проблемы с процессором специальные программы.

Отличным и простым вариантом станет запуск любого популярного архиватора.

Такое приложение серьезно загрузит работой ЦПУ во время архивации файла большого объема.

Если после этого тяжелого процесса архив не сможет открыться или появятся сообщения об ошибке, то с центральным чипом действительно есть проблемы.

Специализированные программы для теста процессора:

Существуют специализированные программы, которые тестируют процессор.

Быстро проверить его работоспособность могут

AIDA64,
LinX,
SiSoftware Sandra, а также другой подобный софт.

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

Ошибки при создании бэкапов

Как я и сказал, пользователи очень любят совершать ошибки про создании резервных копий. Вот основные из них.

Периодичность создания копий

Даже если человек понимает, что резервные копии создавать важно, он все равно в большинстве случаев будет делать это время от времени. Это повышает риск потерять большое количество информации

Лучше всего делать резервные копии по расписанию или по мере внесения изменений. Для этого можно настроить время копирования. Такая функция есть как в Windows, так и в Mac.

Бэкапу все ОС покорны.

Безопасность резервных копий

Любая копия должна храниться в безопасности. Часто пользователи забывают об этом и халатно относятся к хранилищу по принципу ”есть и оно, и ладно”. На самом деле локальное хранилище надо защищать от вирусов и механических повреждений, включая защиту от воды и падений. А еще резервная копия должна храниться не на втором встроенном в компьютер диске, а не внешнем. В этом случае, если компьютер сломается или его украдут, данные будут целы.

Проверка резевной информации

Многие думают, что копия у них есть и можно не переживать, но это в корне неверно. Любой архив надо периодически проверять. Накопитель мог выйти из строя или с ним могло случиться еще что-то, поэтому надо проверять, все ли с ним нормально. Часто такие возможности даже встраиваются в программы, которые создают автоматические копии.

Маркировка резервных копий

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

Только хороший бэкап может решить массу проблем в случае ЧП.

Уведомления об ошибках

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

Хранение данных на разных носителях

Золотое правило резервного копирования гласит, что копии должны храниться в трех местах. Первым из них должен быть обычный HDD, вторым должен быть SSD, а третьим — облачное хранилище. В этом случае вы сведете риск потери данных к настолько низким значениям, что говорить о них будет вообще не серьезно. Выбор разных носителей дает больше надежности, чем простое копирование на два разных SSD или HDD.

Частое создание резервных копий

Я уже говорил о том, что не стоит забывать о резервных копиях, но отдельно стоит отметить, что слишком частыми они не бывают. Например, стандартная утилита Mac, которая называется Time Machine, делает резервные копии раз в час за последний день, раз в день за последнюю неделю и раз в неделю за более ранние периоды. Так риск что-то потерять действительно будет очень небольшим. При такой частоте копирования данные будут возвращаться буквально нажатием кнопки ”назад”. Образно, конечно. Но вы поняли.

Накосячил — откатился. Это как кнопка Home на телефоне.

Следите за исправностью оборудования

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

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

Дальнейшее исследование

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

К утру мы всё ещё думали, что справимся быстро (в КЦ уже начались проблемы). Решили не трогать бренную земную оболочку сервера, а сразу снять с него образ и развернуть на виртуалке. Это стандартная процедура и для форензики, и для восстановления чего-то, где может посыпаться дальше диск, и вообще очень удобно в конечном итоге в плане «не навреди ещё».

Сначала мы развернули виртуалку на стенде прямо у заказчика и начали препарировать там. Фактически Авая сделала больше, чем должна была, подарив лицензию на виртуальную систему. Ну, точнее, заказчику. Выяснили, что бэкап встаёт с ошибкой устройства, но в остальном «норм», правда, система пустая. Довольно быстро стало понятно, что бэкап битый полностью.

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

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

Сохранились конфиги, но улетела вся статистика. У нас закралось сомнение, что они просто какие-то таблицы не добавляли в инкременты. Но в итоге мы нашли бэкап с меткой «полный бэкап» из старых. Развернули его, но пронаблюдали такую же картину.

Бэкап как сервис

Чтобы предотвратить подобные случаи и вовремя выявить неполадки, необходимо регулярно тестировать резервные копии. Пренебрегать валидацией бэкапа не стоит — наоборот, нужно сделать проверку копий частью стратегии резервного копирования.

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

Однако на практике большинство компаний не проверяют резервные копии ни одним из этих методов. Более того, даже в необходимости бэкапа ещё не все убеждены. В далёком 2015 году в компании Backblaze провели опрос пользователей и выяснили, что только 8% опрошенных резервируют данные каждый день, 39% — раз в год, а 25% — никогда.

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

Из-за неосведомленности пользователей и сложности организации самостоятельного тестирования восстановления из резервных копий компании часто игнорируют проверки восстановления из резервных копий. И очень зря — ведь только это гарантирует, что данные удастся восстановить. При этом у провайдеров давно есть технологии, позволяющие тестировать восстановление данных из резервной копии в автоматическом режиме.

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

Большинство крупных Managed IT провайдеров предлагают бизнесу бэкап как сервис

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

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

Как войти в рекавери?

Вход в режим Recovery может отличаться в зависимости от модели (или производителя) устройства. Сейчас мы рассмотрим все способы.

Универсальный способ для всех устройств

Выключаем свой аппарат Андроид (планшет или смартфон), затем зажимаем кнопку включения и делаем короткое нажатие на качельку громкости в сторону увеличения. Готово.

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

Recovery на устройствах Samsung

Если у вас аппарат от производителя «Самсунг», то на инструкции вы видите сначала способ для более современных моделей, а ниже (кнопки 1+ 3) – действия, актуальные для старых боевых корейских товарищей:

Если же у вас планшетный компьютер Samsung, то в recovery попасть можно следующим образом:

Отключаем планшет
Одновременно нажимаем клавиши включения (отключения) и увеличения громкости.

Recovery на Sony Xperia

Для гаджетов на ОС Android от компании Sony существует несколько способов входа в рекавери. Ниже вы видите два варианта:

Если эти манипуляции именно для вашего аппарата оказались недейственными, то можно выполнить следующие шаги:

Выключаем устройство
Нажимаем и удерживаем кнопку питания до появления пары вибраций
Тут же отпускаем клавишу питания и зажимаем качельку звука на увеличение уровня.

Recovery на Nexus

К радости владельцев девайсов марки Nexus, производитель, не мудрствуя лукаво, сделал вход в рекавери совершенно одинаковым для всех своих устройств, поэтому, представленная ниже инструкция абсолютно проста и подходит для всех «Нексусов»:

Recovery на HTC

На устройствах HTC войти в рекавери можно из режима Bootloader. Смотрим видеоинструкцию:

С самого сервера с данными не должно быть доступа к бэкапам

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

Не получится просто купить где-то место в s3, nfs, smb и класть туда бэкапы с серверов. Нужен активный агент, который будет ходить по целевым серверам и собирать данные сам. Зачем такие сложности?

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

Для подобного рода бэкапов хорошо подходят бюджетные vps с большими дисками. Такая услуга, к примеру, есть у ruvds. В списке услуг выбирайте большой диск. Доступен не на всех тарифах и датацентрах.

Выводы

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

Выводы достаточно очевидные: запишите где-нибудь процедуры обслуживания серверов, чтобы их не пропустили, — раз. И проверяйте бэкапы — два. Если у вас есть что-то критичное — или держите это в виртуальной среде, или имейте второе железное решение для бесшовных перезагрузок (ну или готовьтесь к простою). Складируйте бэкапы не на сам сервер, который надо бэкапить. Имейте партнёра со SLA на такие поломки ну или хотя бы просто проверенные контакты, потому что, когда что-то падает, обычно надо решать сразу. Повезло, что это было перед выходными и что на выходных КЦ под минимальной нагрузкой.