Введение
Небольшой магазин использует сервис заказов для связи клиентов, товаров и количества. После подготовленного инцидента пропали два заказа. Ваша задача — вернуть нужные данные, не заменяя независимый публичный каталог. Все люди и записи вымышлены; вредоносного ПО нет.
Резервная копия служит для восстановления. Архив объединяет файлы, а контрольная сумма описывает их байты. Вы узнаете, почему сумма полезна только при доверенном эталоне, и восстановите настоящую базу SQLite через промежуточный каталог. Это ограниченная практика восстановления, а не полная процедура реагирования на инциденты.
Достаточно уметь вводить команды и переключать вкладки. Workstation и App Server — отдельные терминальные сеансы одного учебного узла с разными начальными каталогами, а не разные машины. Веб-интерфейс доступен в Order Service.
Сохраните повреждённые данные сервиса
На этом шаге вы разберётесь в недостающих деловых данных и сохраните копию для отката до изменения сервиса.
Откройте Order Service. Обычно строка связывает номер заказа с клиентом, статусом, товаром и количеством. Нужная точка восстановления содержит три заказа:
| Заказ | Клиент | Статус | Товар | Количество |
|---|---|---|---|---|
| 4101 | Mina | packed | notebook | 1 |
| 4102 | Jon | packed | notebook | 2 |
| 4103 | Asha | packed | notebook | 3 |
Сейчас виден только 4101. Нажмите Public catalog: кружки, блокноты и сумки должны по-прежнему присутствовать. Этот файл не относится к базе и должен сохраниться. Затем вернитесь к заказам.
API — интерфейс сервиса для программ. В Workstation команда curl обращается к API; -f считает ошибки сервера неудачей, -s скрывает прогресс, а -S оставляет сообщения об ошибках. 127.0.0.1 обозначает этот же узел, 8080 — порт сервиса.
curl -fsS http://127.0.0.1:8080/api/orders
Результат — массив JSON, список строк в квадратных скобках. Есть только запись Mina. Успешный запрос не означает полноты деловых данных.
Перейдите в App Server. pwd выводит текущий каталог:
pwd
Ожидается /srv/order-service. SQLite хранит таблицы приложения в orders.db. У подготовленного сервиса нет писателей, он заново открывает базу для каждого запроса, поэтому копирование здесь безопасно. Активной производственной базе нужна процедура резервирования, согласованная с приложением.
cp принимает сначала источник, затем назначение. Сохраните текущую базу вне каталога приложения, чтобы отменить ошибочное восстановление:
cp /srv/order-service/orders.db /home/labex/project/recovery/damaged-before-recovery.db
Отсутствие вывода обычно означает завершение копирования. Не повторяйте команду после восстановления: восстановленная база перезапишет копию для отката. Повреждённое состояние сохранено; сам сервис ещё предстоит восстановить.
Выберите доверенный архив восстановления
На этом шаге вы отвергнете изменённые байты и поместите подходящий проверенный архив в промежуточный каталог.
Перейдите в Workstation. cd меняет каталог, ls показывает его содержимое. Абсолютный путь начинается с / и не зависит от текущего каталога.
cd /home/labex/project/recovery/backups
ls
Есть три архива .tar.gz: tar объединяет файлы, gzip сжимает их. Имена описывают время восстановления; самая новая копия не обязательно безопасна и подходит.
cat выводит текстовый файл. Прочитайте описания точек, отдельно предоставленные хранителем копий:
cat /opt/backup-custodian/recovery-points.txt
Архив 0800 предшествует заказам 4102 и 4103. 0900 включает нужную точку. Кандидат 1000 позднее, но его целостность тоже надо проверить.
Целостность означает неизменность байтов относительно эталона. SHA-256 создаёт дайджест для сравнения. Манифест хранителя принадлежит root и находится вне обычного редактируемого каталога восстановления. Сценарий предполагает независимый защищённый канал доставки; подписи и распространение ключей здесь не изучаются. Администратор может обойти локальное владение, поэтому учебный узел не является неуязвимым якорем доверия.
sha256sum -c читает пары имя/дайджест и сравнивает соответствующие файлы текущего каталога. Используйте независимый манифест:
sha256sum -c /opt/backup-custodian/SHA256SUMS
0800 и 0900 должны показать OK, 1000 — FAILED. Ненулевой код и предупреждение ожидаемы: как минимум один архив изменён. Не извлекайте этот кандидат.
Соседний манифест можно менять вместе с копиями. Сравните результат:
sha256sum -c SHA256SUMS
Все три показывают OK. Тот, кто меняет архив, может заменить и сумму рядом. Совпадение с недоверенным дайджестом не доказывает подлинности. 0800 не изменён, но не содержит нужных записей. Выберите 0900: он неизменён и подходит.
Промежуточный каталог позволяет проверить данные до вмешательства в работающий сервис. mkdir -p создаёт каталог и допускает его существование:
mkdir -p /home/labex/project/recovery/stage
Скопируйте туда проверенный кандидат:
cp orders-0900.tar.gz /home/labex/project/recovery/stage/orders-0900.tar.gz
При ошибке в источнике cp сообщит, что файл не найден; проверьте ls и повторите. Контроль оценивает реальные байты подготовленного архива, а не письменное заявление о проверке.
Проверьте промежуточную базу
На этом шаге вы просмотрите состав архива, извлечёте единственный ожидаемый файл и прочитаете подготовленную базу без изменений.
В Workstation перейдите в промежуточный каталог:
cd /home/labex/project/recovery/stage
tar -tvzf показывает состав gzip-архива: t — список, v — тип и права, z — gzip, f — имя архива. Просмотр ничего не извлекает.
tar -tvzf orders-0900.tar.gz
Единственным участником должен быть orders.db; поле прав начинается с -, обозначая обычный файл. При абсолютных путях, компонентах .., ссылках или неожиданных файлах остановитесь. Проверка имён полезна здесь, поскольку доверенный учебный архив содержит один обычный файл; это не полная политика безопасной распаковки произвольных архивов. Никогда не запускайте программы из подозрительной копии.
Для извлечения используйте x вместо t, убрав подробный режим v. Последний orders.db ограничивает извлечение этим файлом, а --no-same-owner сохраняет ваше владение:
tar -xzf orders-0900.tar.gz --no-same-owner orders.db
SQLite хранит связанные таблицы в одном файле. Подготовленный инструмент db-view открывает базу только для чтения, проверяет внутреннюю согласованность и связи и показывает объединённые деловые строки. Писать SQL или редактировать базу не нужно. Передайте путь подготовленного файла:
/opt/c11-runtime/db-view /home/labex/project/recovery/stage/orders.db
Ожидаются Integrity: ok, Relationships: ok и все три заказа. Исправная база может относиться к неправильному моменту: сравните клиентов, статусы и количества с шагом 1.
Неверный путь вызывает ошибку, а не создание пустой базы. Проверьте pwd и ls, затем повторите. При других данных вернитесь к независимому манифесту и выберите правильный архив до повторного извлечения. Сайт всё ещё повреждён: подготовка сама по себе не восстанавливает приложение.
Восстановите и проверьте работающий сервис
На этом шаге вы замените только назначенную базу и подтвердите восстановление настоящими запросами, сохранив публичный файл.
Перейдите в App Server. Копия для отката находится вне этого каталога, а подготовленная база прошла проверку. Скопируйте только её в назначенный путь приложения:
cp /home/labex/project/recovery/stage/orders.db /srv/order-service/orders.db
Источник и назначение — разные файлы. Не копируйте весь промежуточный каталог поверх /srv/order-service: там находятся посторонние файлы, которые надо сохранить. Перезапуск демона не нужен: подготовленное приложение только для чтения закрывает базу после каждого запроса. Другим приложениям может требоваться документированное обслуживание или перезапуск.
Обратитесь к приложению вместо того, чтобы полагаться на наличие копии или текстового файла restored:
curl -fsS http://127.0.0.1:8080/api/orders
Ожидаются 4101, 4102 и 4103 с верными клиентами, статусом packed и количествами 1, 2, 3. Откройте Order Service и обновите страницу: таблица должна совпадать.
Проверьте и независимый публичный файл:
curl -fsS http://127.0.0.1:8080/uploads/catalog.txt
Public catalog: mugs, notebooks, tote bags
Нажмите Public catalog в браузере и подтвердите содержимое. Восстановление означает возврат нужных данных при сохранении посторонних нормальных функций.
Если сервис сообщает Database unavailable, снова проверьте промежуточную базу и повторите копирование одного файла с правильными абсолютными путями. Чтобы вернуться к повреждённому исходному состоянию во время поиска ошибки, используйте сохранённую копию:
cp /home/labex/project/recovery/damaged-before-recovery.db /srv/order-service/orders.db
Последняя команда намеренно отменяет восстановление. Если вы её использовали, перед завершением снова скопируйте проверенную промежуточную базу в активный путь. Сохраните файл отката для дальнейшего разбора.
Резюме
Вы сохранили копию для отката, сравнили байты с независимым доверенным манифестом, выбрали подходящий момент и проверили промежуточную базу SQLite. Затем восстановили настоящий сервис и проверили связи и посторонний публичный файл. Новизна, неизменность и пригодность — разные свойства; безопасное восстановление требует их правильного сочетания.
