Files
admin d8e01f3398
continuous-integration/drone/push Build is passing
fix(backup): exclude TDLib's disposable file cache from the tdlib tar
files/temp is TDLib's own redundant download cache — the worker
already prunes it after every ingestion run (see the recent
optimizeTdlibStorage fix), and its content still lives in the
source/destination Telegram chats regardless. With the cache grown
back to ~59GB between prune cycles, tarring it made today's backup
run for 4+ hours straight, fighting the actively-ingesting worker for
disk I/O and degrading the whole host. Excluding it keeps the backup
to what's actually irreplaceable: the DB dump and the TDLib session
state itself.
2026-08-14 11:40:03 +02:00

39 lines
1.3 KiB
Bash

#!/bin/bash
set -euo pipefail
report_failure() {
[ -n "${KUMA_PUSH_URL:-}" ] || return 0
curl -fsS "$KUMA_PUSH_URL" --get \
--data-urlencode "status=down" \
--data-urlencode "msg=$BASH_COMMAND failed" || true
}
trap report_failure ERR
DUMP_FILE=/tmp/dragonsstash.dump
TAR_FILE=/tmp/tdlib.tar.gz
trap 'rm -f "$DUMP_FILE" "$TAR_FILE"' EXIT
pg_dump -h dragonsstash-db -U "$POSTGRES_USER" -d "$POSTGRES_DB" -Fc -f "$DUMP_FILE"
# TDLib volumes are tarred live (best-effort, per design). A file changing
# mid-read makes GNU tar exit 1 (warning) — that is expected here and must not
# abort the backup. Only a genuine error (exit >= 2) is fatal.
#
# files/temp is TDLib's own disposable download cache (redundant with the
# source/destination Telegram chats, pruned by the worker itself after each
# ingestion run) — it has no business in a backup and its size is what made
# this tar take 4+ hours once the cache grew back to tens of GB.
tar --warning=no-file-changed --exclude='tdlib-worker/*/files/temp' \
-czf "$TAR_FILE" -C /data tdlib-worker tdlib-bot \
|| { rc=$?; [ "$rc" -le 1 ] || exit "$rc"; }
restic backup "$DUMP_FILE" "$TAR_FILE"
restic forget --keep-daily 14 --prune
if [ -n "${KUMA_PUSH_URL:-}" ]; then
curl -fsS "$KUMA_PUSH_URL" --get \
--data-urlencode "status=up" \
--data-urlencode "msg=OK"
fi