Молоток против сервера

Есть звонки, после которых сразу понятно — сегодня будет непростой день. Женщина на другом конце провода говорила коротко и очень тревожно: «Сервер не запускается». За такой фразой обычно стоит что-то банальное — скачок напряжения, умерший блок питания, максимум — накрывшийся диск. Она позвонила по чьей-то рекомендации, что в айтишной среде работает надёжнее любой рекламы. Компания занималась бухгалтерским аутсорсингом — а значит, весь бизнес был завязан на одной вещи: базах 1С. Отчётность, зарплаты, налоги десятков клиентов — всё лежало в одном железном ящике где-то в подсобке.

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

Открываем корпус.

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

Ни один диск, разумеется, не читался.

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

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

Когда данные вернулись, началась вторая часть работы — менее киногеничная, зато куда более важная: объяснить, почему такое вообще стало возможным.

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

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

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