Восстановление базы данных ERP и выгрузка финансовой аналитики

Восстановление базы данных ERP и выгрузка финансовой аналитики

1. Введение и цель работы

• Цель: Извлечение базы данных вендинговой ERP-системы из облачного хранилища Yandex Cloud.

• Ограничения:

• Исходный разработчик системы недоступен.

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

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

2. Анализ вариантов доступа к данным (Консультации и выбор стратегии)

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

1. Попытка подбора/сброса пароля учетных записей через Серийную консоль ВМ. Отклонено из-за отсутствия локального пароля root/пользователя в конфигурации гостевой ОС.

2. Прямое включение оригинальной ВМ с назначением публичного IP. Отклонено: в облаке Yandex Cloud публичный SSH-ключ инжектируется метаданными cloud-init только в момент первичного вм и не обновляется на уже существующей машине штатным образом.

3. Восстановление через Live-CD/Rescue-режим. Сложный в реализации сценарий в облачной инфраструктуре с повышенным риском изменения оригинального диска.

4. Снятие снимка (Snapshot) с оригинального диска, создание независимого тома и подключение его как второго диска к новой служебной ВМ.

Итоговое решение: Выбран вариант 4 как наиболее безопасный, изолированный и исключающий влияние на оригинальный продуктовый накопитель.

3. Работа в инфраструктуре Yandex Cloud

• Очистка общего дискового пространства: Проведена ревизия облачного хранилища, удалены устаревшие снимки дисков от 2023 года для высвобождения квоты и снижения затрат на хранение.

• Снятие копии и создание тома: С оригинального системного диска ERP объемом 1 ТБ был успешно сформирован снимок состояния, после чего развернут отдельный дисковый том.

• Развертывание служебного инстанса:

• Создана временная прерываемая (preemptible) виртуальная машина для минимизации тарификации.

• К ней смонтирован созданный диск с данными.

• Организация доступа:

• Поскольку прямой доступ по SSH с локальной машины блокировался сетевыми правилами/ключами, управление развертыванием и монтированием диска было выполнено через встроенный Yandex Cloud Shell.

• Диск был смонтирован в файловую систему служебной машины (/mnt/snapshot_data).

• В каталоге /mnt/snapshot_data/home/erpdb/prod обнаружены неповрежденные системные файлы СУБД PostgreSQL 14 (общий объем исходной директории — 42 ГБ).

4. Экспорт и передача данных на локальный контур

• Устранение проблем с целостностью архива:

• Первичная попытка прямой передачи потока через перенаправление вывода в Windows PowerShell привела к повреждению архива (попадание BOM ff fe и искажение кодировки UTF-16LE).

• Проблема была локализована: архивация базы данных была перенесена непосредственно на сторону виртуальной машины в Linux.

• Архивация на сервере:

• Внутренними средствами Linux сформирован чистый сжатый gzip-архив erpdb.tar.gz.

• Фактический объем сжатого архива составил ~25.6 ГБ (размер исходных данных до сжатия — 42 ГБ).

• Передача данных:

• Скачивание выполнено по протоколу SCP напрямую на локальный диск E:\ с сохранением бинарной структуры байт-в-байт:

  scp -i C:\Users\Rustam.ssh\id_ed777 [email protected]:/tmp/erpdb_prod.tar.gz E:\erpdb.tar.gz

• Завершение облачного этапа:

• Целостность архива подтверждена локально.

• Временная виртуальная машина и смонтированный диск в Yandex Cloud выключены и удалены для полной остановки тарификации.

5. Развертывание локального окружения и исследование БД

• Распаковка архива:

• Архив распакован средствами утилиты tar в каталог E:\prod.

• Валидация файла E:\prod\PG_VERSION подтвердила версию ядра СУБД: PostgreSQL 14.

• Запуск изолированной среды (Docker Desktop):

• Для обхода ограничений прав доступа Windows NTFS база запущена в легковесном контейнере с трансляцией портов 5432:5432 и оригинальным UID владельца данных 999:1001.

• Восстановление прав доступа к СУБД:

• Так как в исходной ERP-системе стандартный суперпользователь postgres отсутствовал/был переименован, СУБД была запущена в служебном однопользовательском режиме ядра (postgres --single), где была создана административная роль postgres с полными привилегиями доступа.

• Идентификация структур и данных:

• Определена рабочая база данных — COMPANYDB и прикладная схема — company.

• Проведен аудит наполнения таблиц: обнаружена главная таблица фиксации продаж вендинговых аппаратов — company.t_vm, насчитывающая 20 777 777 записей.

• Определены ключевые поля учета выручки: servertime (дата и время фиксации продажи), price (цена напитка), cashlessamount (фактическая безналичная оплата) и discountamount (скидки).

6. Результаты и выгрузка аналитики

1. Расчет финансовых показателей:

• Сформирован сводный аналитический отчет помесячной динамики за период с января 2023 года по сентябрь 2026 года (45 отчетных месяцев).
• Вычислены ключевые метрики: суммарная выручка в рублях, общее количество проданных чашек, средняя цена чека.

2. Экспорт данных:

• Отчет успешно экспортирован в структурированный формат CSV с разделителем ; и кодировкой UTF-8 (E:\prod\monthly_revenue.csv), полностью совместимый с Microsoft Excel.

3. Консервация рабочего контура:

• Локальный контейнер с базой данных безопасно остановлен (docker stop local_erp_db).
• Сформирована полная техническая инструкция по повторному запуску и извлечению любых срезов данных из таблицы t_vm в будущем.

7. Зачистка облака от всех виртуальных машин, дисков, источников расходов

• В облачном каталоге аккаунта vendingdigital удалены 10 неиспользуемых дисков и 8 выключенных виртуальных машин.

• Проведен аудит оставшихся тарифицируемых ресурсов: обнаружены и освобождены 2 не привязанных статических IP-адреса, генерировавших скрытые списания.

• Сохранена работа сервиса Yandex Captcha в соответствии с требованиями заказчика.