Обновление

cd /opt/buglapse && sudo ./buglapse upgrade

Это обновит до последней версии. Конкретная версия — ./buglapse upgrade --to 1.2.0. О новой версии сообщает Администрирование → Система — там же готовая команда.

Во время обновления события не теряются: SDK продолжают отправлять, Buglapse продолжает принимать, и всё принятое ждёт в очереди, пока новая версия не начнёт работу. Панель на эти минуты показывает «Идёт обновление Buglapse» и откроется сама, когда всё будет готово.

Что происходит

1. Проверка — ничего не трогая: скачиваются образы, хватит ли места на диске для бэкапа базы и памяти Redis на полчаса событий.
2. Режим обновления — приём событий складывает их в Redis, фоновые задачи доделывают начатое (до 10 минут) и останавливаются. Не успели — обновление отменяется, ничего не изменено.
3. Бэкап базы в backups/ — согласованный: в базу в этот момент никто не пишет.
4. Миграции — в отдельных временных контейнерах, через все промежуточные версии, затем до целевой.
5. Новая версия поднимается во втором слоте рядом со старой, проверяет базу и отправляет пробное событие через настоящий endpoint приёма.
6. Переключение — прокси отправляет трафик в новый слот, старый завершает запросы и останавливается, новая версия разбирает накопившуюся очередь.

Скрипт ./buglapse обновляет себя сам: если в новой версии он изменился, обновление продолжает уже новый. Лог каждого обновления — backups/{время}-upgrade.log.

Если обновление не удалось

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

Промежуточные версии

Некоторые релизы — остановки: миграции между ними сжаты, и база должна пройти через каждую. Обновляться можно с любой версии сразу до последней — ./buglapse upgrade сам находит остановки по пути и проходит их одну за другой (Release stops on the way: …). Образы остановок остаются в registry всегда.

Без бэкапа

На большой базе дамп может занять долго. Если у вас свои снимки диска или базы:

sudo ./buglapse upgrade --no-backup

Тогда при сбое откатить базу некому: инстанс остаётся в режиме обновления — события принимаются в очередь, — пока вы не восстановите базу из своего снимка и не выполните ./buglapse restore-done. Старая версия разберёт очередь.

Откат на старую версию

Версия базы только растёт — запустить старую версию на обновлённой базе нельзя. Путь назад — дамп, сделанный перед обновлением: ./buglapse restore вернёт и базу, и версию, к которой она относится.

Бэкапы

./buglapse upgrade делает дамп перед каждым обновлением и хранит три последних. Регулярные бэкапы — ваша задача. Что сохранять:

Что	Где	Как
База	том buglapse_postgres	pg_dump, ниже
.env	каталог установки	Копией файла. Без APP_KEY из него секреты в базе не расшифровать
Файлы	том buglapse_storage	Записи сессий и npm-пакеты SDK, если они не в S3

Дамп базы — без остановки, в формате, который понимает ./buglapse restore:

cd /opt/buglapse
VERSION=$(sed -n 's/^\(BLUE\|GREEN\)_VERSION=//p' .slots | grep -v none | head -n1)
docker compose exec -T postgres pg_dump -U buglapse -d buglapse -Fc \
> "backups/$(date -u +%Y%m%d-%H%M%S)-$VERSION.dump"

Имя файла важно: {дата}-{время}-{версия}.dump — по нему restore понимает, какой версии Buglapse принадлежит база.

Файлы — например, архивом тома:

docker run --rm -v buglapse_storage:/data -v "$PWD/backups:/backup" alpine \
    tar czf /backup/storage-$(date -u +%Y%m%d).tar.gz -C /data .

Восстановление

cd /opt/buglapse && sudo ./buglapse restore backups/20261019-031500-1.0.0.dump

Скрипт переводит инстанс в режим обновления (события копятся в очереди), заменяет базу дампом и, если дамп от другой версии, поднимает эту версию во втором слоте и переключается на неё. Затем принятые за это время события обрабатываются.

Осторожно

Восстановление заменяет базу целиком: всё, что записано после дампа, пропадёт.

Перенос на другой сервер

1. Создайте каталог /opt/buglapse и положите в него старый .env — установщик возьмёт из него домен, ключ лицензии и APP_KEY.

2. Перенаправьте A-запись домена на новый сервер.

3. Установите, не создавая первый аккаунт — он придёт с базой:

   curl -fsSL https://app.buglapse.com/api/self-hosted/install.sh | sudo bash -s -- --skip-organization

4. Скопируйте дамп в /opt/buglapse/backups/ и выполните sudo ./buglapse restore backups/….dump.

5. Верните файлы в том buglapse_storage, если они не в S3.

Состояние

sudo ./buglapse status

Domain:        errors.example.com
Active slot:   green (1.0.1)
Database:      1.0.1
Intake-only:   off

Intake-only: on since … вне обновления значит, что обновление прервалось на полпути (например, с --no-backup); скрипт в таком случае пишет, что делать дальше.