Молоток против сервера
Компании редко обращаются за помощью сразу после того, как что-то пошло не так. Обычно этому предшествует цепочка событий, о которой сначала никто не рассказывает.
Этот случай начинался как авария сервера, но довольно быстро стало понятно, что искать причину придётся далеко не в технике.
В этой истории
Есть звонки, после которых сразу понимаешь — сегодня будет непростой день. Этот был именно таким.
Позвонила женщина по чьей-то рекомендации — «сарафанное радио» в айтишной среде работает надёжнее любой рекламы. Она держала компанию, занимающуюся бухгалтерским аутсорсингом — а значит, весь бизнес держался на одной вещи: на базах 1С. Клиентские данные, отчётность, зарплаты, налоги десятков компаний — всё в одном месте.
Проблема была сформулирована коротко и тревожно: «Сервер не запускается».
За этой фразой обычно скрывается что угодно — от банального сбоя питания до отказа диска. Но за ней редко скрывается история человеческого конфликта, ставшая физической.
Приезд
Перед тем как чинить, нужно понять, что и как настроено, кто и что делал раньше. Выясняется деталь: до нас с клиенткой долго работал приходящий специалист. И в какой-то момент между ними что-то сломалось. Не сервер — отношения. Коммуникация оборвалась настолько, что вслед за ней оборвался и доступ к информации.
Открываем корпус сервера — и картина проясняется.
Все жёсткие диски, которые там стояли, несут следы физических повреждений. Классические вмятины — судя по всему, кто-то приложился к информации молотком. Причём не единожды и не аккуратно.
Естественно, ни один диск не читался.
Что было дальше
Есть подозрение, что удары наносились без особого «профессионализма» — то ли в спешке, то ли в состоянии эмоций, которые к бережному обращению с техникой не располагают. Но повреждения оказались достаточно серьёзными, чтобы своими силами восстановить данные было невозможно.
Подключили коллег, специализирующихся на восстановлении данных с повреждённых носителей. Ребята сработали профессионально — реанимировали диски и вытащили практически всё. Для клиентки, чей бизнес держался на этих базах, это было спасением.
Урок, который стоило усвоить раньше
Когда данные вернулись, началась вторая, менее драматичная, но куда более важная часть работы — объяснить, почему такая ситуация вообще стала возможной.
Ключевая ошибка была системной: резервные копии баз 1С хранились на том же самом диске, что и сами базы. То есть при любом сбое — физическом, логическом, злонамеренном — под удар попадало абсолютно всё разом. Не осталось бы точки восстановления, потому что резервная копия погибла бы вместе с оригиналом.
Собственно, молоток это наглядно и продемонстрировал.
Что сделали
Решение выстроили в несколько уровней:
- Отдельный физический диск — под резервное копирование, изолированный от рабочих баз, с ограниченным доступом.
- Вторая копия в облаке — на Яндекс.Диске, с доступом исключительно у руководителя компании, без посредников и приходящих специалистов.
Простая, но принципиальная схема: данные больше не живут в одной точке, которую можно уничтожить одним ударом — в прямом смысле слова.
Итог
Схема работает до сих пор без сбоев. А история осталась хорошей иллюстрацией правила, которое кажется банальным, пока не столкнёшься с ним на практике: бэкап, который лежит рядом с оригиналом — это не бэкап. Особенно если рядом с сервером когда-то может оказаться не только IT-специалист, но и молоток.