Введение
Резервная копия полезна только в том случае, если с её помощью можно восстановить данные приложения. Вы экспортируете небольшую базу данных D1 в SQL, восстановите вторую временную базу данных из экспортированного файла и сравните данные и ограничения, не изменяя исходную базу.
Эта лабораторная работа начинается независимо с двумя синтетическими заявками и использует не более двух баз данных D1. Резервная копия остаётся на вашей виртуальной машине LabEx; учётная запись или бакет объектного хранилища в этом процессе не используются.
Используйте собственную учебную учётную запись и новую виртуальную машину. Сначала настройка установит Node.js 22.22.0, затем выполнит npm install для локального Wrangler 4.131.1 и всех зависимостей для проверки в каталоге /home/labex/project/ticket-database. Версии прямых зависимостей зафиксированы; установка создаёт собственный lock-файл. Во время настройки не выполняются вход в облако и операции с проверяемой базой данных. На личном компьютере установите ту же версию Wrangler с помощью npm install --save-dev wrangler@4.131.1 в каталоге проекта.
В этом упражнении используются небольшие синтетические записи в пределах бесплатных лимитов D1. Использование ресурсов, уже накопленное в учётной записи, также учитывается в этих лимитах. Покупать домен не нужно. Не закрывайте эту виртуальную машину, пока не проверите удаление ресурсов и выход из учётной записи.
Авторизуйте эту виртуальную машину и выберите учётную запись
На этом шаге вы подключите новый терминал к собственной учебной учётной записи. Одного входа в Dashboard недостаточно для авторизации виртуальной машины. Разрешение D1 позволяет создавать базы данных, изменять SQL-данные и удалять базы данных. Перед авторизацией ознакомьтесь с фактической страницей согласия, включая раздел Background Access.
Откройте подготовленный проект и проверьте зафиксированную версию CLI:
cd /home/labex/project/ticket-database
npx wrangler --version
Ожидаемый результат — 4.131.1. Запустите авторизацию устройства. Параметр --device выводит код для браузера, а --browser=false позволяет вам самостоятельно выбрать способ открытия браузера:
npx wrangler login --device --browser=false --scopes account:read user:read d1:write
Откройте показанный URL в браузере, введите текущий код, подтвердите свою учебную учётную запись и разрешения, затем авторизуйтесь. Дождитесь подтверждения успешной авторизации в терминале. Никогда не вставляйте пароли или токены в файлы проекта.
npx wrangler whoami --json
Проверьте значение loggedIn: true, затем прочитайте name и id учётной записи, даже если отображается только одна учётная запись. Скопируйте нужный идентификатор в конфигурацию ниже. Следующая переменная оболочки использует 6 случайных байт (12 шестнадцатеричных символов), чтобы избежать совпадений с другими учащимися. Here-document записывает JSON между строками JSON; переменная $RUN раскрывается внутри этого блока.
Обратная косая черта перед $schema сохраняет этот ключ JSON буквально; $RUN по-прежнему подставляет уникальное имя текущего запуска.
RUN=labex-c04-d06-$(openssl rand -hex 6)
cat > wrangler.jsonc <<JSON
{
"\$schema": "./node_modules/wrangler/config-schema.json",
"name": "$RUN",
"account_id": "YOUR_ACCOUNT_ID",
"main": "src/index.js",
"compatibility_date": "2026-09-15",
"workers_dev": true,
"preview_urls": false
}
JSON
Перед запуском блока замените YOUR_ACCOUNT_ID. Не закрывайте этот терминал, чтобы переменная RUN оставалась доступной. Поле name идентифицирует этот запуск, а account_id выбирает учётную запись для облачных операций. Файл содержит обычный JSON, который также является допустимым JSONC. При его создании Worker не разворачивается.
Подготовьте базу данных, которую нужно сохранить
На этом шаге вы создадите небольшую исходную базу данных. Настройка предоставляет схему заявок; ваша задача — экспортировать и восстановить эту базу вместе с её ограничениями, не изменяя исходную.
Создайте временную облачную базу данных. Параметр --binding DB задаёт короткое имя для кода приложения, --update-config записывает её фактическое имя и UUID в wrangler.jsonc, а --use-remote=false оставляет разработку локальной:
npx wrangler d1 create "$RUN-db" --binding DB --update-config --use-remote=false
Прочитайте созданные имя и идентификатор, затем проверьте сохранённую привязку:
cat wrangler.jsonc
Запись DB должна содержать имя базы данных этого запуска. Привязка — это настроенное соединение между кодом и ресурсом. Её UUID идентифицирует облачную базу данных, а параметр --local использует отдельную базу SQLite на этой виртуальной машине. В командах SQL всегда явно указывайте либо --local, либо --remote.
cat schema.sql
npx wrangler d1 execute DB --remote --file schema.sql
Перед экспортом прочитайте исходные данные и схему:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; SELECT sql FROM sqlite_master WHERE type = 'table' AND name = 'tickets';"
В базе должны быть две заявки. Зафиксируйте ожидаемые значения: заявка с ID 1 — Cannot sign in, её статус — open; заявка с ID 2 — Invoice copy, её статус — closed. Для обеих заявок значение source равно seed. Схема содержит первичный ключ, обязательные значения и ограничение для статуса.
Экспортируйте полную резервную копию SQL
На этом шаге вы создадите переносимый SQL-файл. Экспорт описывает определения таблиц и данные в виде SQL; импорт этого файла позволяет восстановить базу данных в другом месте. Это отличается от D1 Time Travel, который восстанавливает историю на месте.
Параметр --remote выбирает облачный источник, а --output задаёт имя файла, который будет записан на этой виртуальной машине. Сохраните и схему, и данные, не указывая --no-schema и --no-data:
npx wrangler d1 export DB --remote --output backup.sql
Если появится запрос, подтвердите точную исходную базу данных. Проверьте небольшой экспортированный файл:
cat backup.sql
Найдите команды CREATE TABLE и операторы INSERT для заявок. Формат экспорта, заключение имён столбцов в кавычки и внутренние операторы могут отличаться от исходного SQL, написанного вручную. Успешная загрузка файла сама по себе не доказывает возможность восстановления; на следующем шаге вы проверите файл, восстановив из него базу данных. Файл содержит только синтетические данные. Храните его на виртуальной машине; бакет R2 не требуется.
Восстановите отдельную базу данных
На этом шаге вы восстановите данные во второй пустой базе, не затрагивая исходную. Отдельная целевая база позволяет сравнить восстановленные данные до изменения привязки приложения.
Создайте второй ресурс с привязкой REBUILT. Обновление конфигурации добавит его рядом с DB:
npx wrangler d1 create "$RUN-copy" --binding REBUILT --update-config --use-remote=false
cat wrangler.jsonc
Проверьте, что у двух привязок разные UUID баз данных, а их имена соответствуют ожидаемым суффиксам -db и -copy. Импортируйте данные только в REBUILT:
npx wrangler d1 execute REBUILT --remote --file backup.sql
Эта команда выполняет экспортированный SQL в новой облачной целевой базе. Подтвердите эту целевую базу в запросе. Затем выполните запрос:
npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id; PRAGMA table_info(tickets);"
Строки и определения столбцов должны совпадать с исходной базой. Проверьте одно из восстановленных ограничений с помощью недопустимой вставки:
npx wrangler d1 execute REBUILT --remote --command "INSERT INTO tickets (id, subject, status, source) VALUES (3, 'Invalid', 'lost', 'probe');"
Ожидаемый результат — CHECK constraint failed. Преднамеренно неудачная операция не должна добавить третью строку. Снова прочитайте обе базы данных:
npx wrangler d1 execute DB --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
npx wrangler d1 execute REBUILT --remote --command "SELECT id, subject, status, source FROM tickets ORDER BY id;"
В обеих базах по-прежнему должны находиться ровно две исходные строки. Откройте в Dashboard два ресурса с точными именами и выполните контрольную проверку только для чтения; перед просмотром восстановленной таблицы убедитесь, что их идентификаторы различаются. Никогда не перезаписывайте другую базу данных для проверки восстановления.
В этом примере показаны два восстановленных обращения в базе -copy. Сгенерированное имя обозначает этот пример запуска; ваши имена ресурсов и UUID будут другими. Снимок подтверждает только видимые строки. Команды экспорта и импорта CLI и независимые проверки выше подтверждают восстановление, совпадение схемы и сохранение ограничений.
Удалите временные ресурсы
На этом шаге вы удалите только ресурсы этой лабораторной работы, пока виртуальная машина всё ещё авторизована. Сначала завершите все функциональные проверки. Сохраняйте конфигурацию до окончания проверки удаления.
npx wrangler d1 delete REBUILT
npx wrangler d1 delete DB
Проверьте текст запроса и подтвердите удаление только базы данных этого запуска. Затем выведите список баз данных:
npx wrangler d1 list --json
В успешном ответе не должны присутствовать ни имена, ни UUID обеих записанных баз данных. Другие ресурсы могут остаться. Ошибка аутентификации или сети не даёт окончательного результата: восстановите доступ и повторите чтение списка перед продолжением. Выполните проверку этого шага, пока вы всё ещё вошли в систему.
Завершите авторизацию этой виртуальной машины
На этом шаге завершите авторизацию только после успешной независимой проверки удаления. Выход удаляет сохранённые на этой виртуальной машине данные авторизации Wrangler; одного закрытия виртуальной машины недостаточно для очистки облачных ресурсов.
npx wrangler logout
npx wrangler whoami --json
Ожидаемый результат — loggedIn: false. Неаутентифицированный запрос может завершиться с ненулевым кодом; это нормально только в том случае, если структурированный ответ явно сообщает, что вы вышли из системы. Завершите проверку, затем закройте среду лабораторной работы.
Резюме
Вы потренировались экспортировать и восстанавливать базу данных. Вы проверили наблюдаемые результаты работы базы данных, явно указали выбранную учётную запись и локальное состояние, а затем удалили временные ресурсы перед выходом из системы.
