mirror of
https://github.com/MBombeck/HealthLog.git
synced 2026-11-08 12:32:43 +00:00
Marc-André Bombeck
1e09f30eff
A stored backup was one value in data_backups.data. v1.39.1 wrote it a piece at a time but still joined the pieces into that one value, and one value has to pass through the app whole, so a copy was capped at a fifth of the heap: 105 MB in the default 1 GB container. An account with 1.75 million readings is past that and could not be backed up at all (#1031). A copy is now kept as ordered pieces of about a megabyte in the new data_backup_chunks table (migration 0352). Each piece is sealed on its own with AES-256-GCM, and its sealed header names the copy (a random stream id kept on the row), its position and whether it is the last. A reader checks every piece before it releases a byte, so a piece that is missing, moved, altered, taken from another copy, or a copy cut short is refused with backup.payload.undecryptable before a restore deletes anything, and the second read during the restore checks each piece again. The write is one transaction, so the previous copy stays whole and readable until the new one commits. Pieces are written through the model API: a raw query with a large parameter is kept alive by Prisma's query plan cache, which left 160 MB of heap behind per hundred one-megabyte inserts. Restore, preview, download, the restore job and the admin list read both forms; copies written before this change keep their single value and still restore. The heap-derived limit is gone. The one limit left is on storage, BACKUP_MAX_STORED_MB (default 2048), and its message names the setting. Key rotation covers the pieces, the wipe and account deletion take them with their backup, and the backup plan lists the table as not carried. Measured on an account of 2.6 million readings in a 1 GB container with web and worker in one process: backup 87 s, 97 MiB in 96 pieces, preview 20 s, download 25 s, restore 264 s with every reading back exactly, peak 567 MiB, no restart.
39 lines
1.6 KiB
SQL
39 lines
1.6 KiB
SQL
-- Stored backups in pieces.
|
|
--
|
|
-- A backup used to be one `text` value in `data_backups.data`. One value has
|
|
-- to pass through the app as one value on its way in and out, so the largest
|
|
-- backup a host could keep was tied to the app's memory: a fifth of its heap
|
|
-- limit, 105 MB in the default 1 GB container, which an account with 1.75
|
|
-- million readings outgrew (#1031). A copy is now written as ordered pieces of
|
|
-- about a megabyte each, and nothing about its size depends on memory.
|
|
--
|
|
-- Additive for existing rows: a copy written before this migration keeps its
|
|
-- single value and stays readable as it is. The next weekly run replaces the
|
|
-- weekly copy in the new form; an uploaded copy keeps its old form until it is
|
|
-- deleted.
|
|
|
|
-- AlterTable
|
|
ALTER TABLE "data_backups" ALTER COLUMN "data" DROP NOT NULL,
|
|
ADD COLUMN "chunk_count" INTEGER,
|
|
ADD COLUMN "chunk_stream_id" TEXT;
|
|
|
|
-- CreateTable
|
|
CREATE TABLE "data_backup_chunks" (
|
|
"id" TEXT NOT NULL,
|
|
"backup_id" TEXT NOT NULL,
|
|
"seq" INTEGER NOT NULL,
|
|
"data" BYTEA NOT NULL,
|
|
|
|
CONSTRAINT "data_backup_chunks_pkey" PRIMARY KEY ("id")
|
|
);
|
|
|
|
-- CreateIndex
|
|
CREATE UNIQUE INDEX "data_backup_chunks_backup_id_seq_key" ON "data_backup_chunks"("backup_id", "seq");
|
|
|
|
-- AddForeignKey
|
|
ALTER TABLE "data_backup_chunks" ADD CONSTRAINT "data_backup_chunks_backup_id_fkey" FOREIGN KEY ("backup_id") REFERENCES "data_backups"("id") ON DELETE CASCADE ON UPDATE CASCADE;
|
|
|
|
-- Ciphertext does not compress, so storing it uncompressed saves the attempt;
|
|
-- it still moves out of line like any large value.
|
|
ALTER TABLE "data_backup_chunks" ALTER COLUMN "data" SET STORAGE EXTERNAL;
|