Skip to content

p6: backup for the LiteLLM database and fleet state #19

Description

@andrewmusselman

With fleet state in LiteLLM, there is one artifact rather than two.

sudo -u postgres pg_dump litellm | gzip > "$dest/litellm-$stamp.sql.gz"

$dest is the open question. Three constraints:

  • the destination must be captured off-host. bpc_client_asf pulls via
    rsync from a central BackupPC server, so the client has no local daemon and
    coverage cannot be confirmed from the box. The share list lives on the
    server — ask Infra which paths are pulled rather than assuming. A default
    share of /etc and /home would miss /var/backups
  • confirm the host is not in bpc_client_asf::excludelist
  • a file-level copy of a live Postgres data directory is not a valid
    backup; the pg_dump is what makes it restorable
    What is at stake, and it grew with "LiteLLM routes have no api_base": Postgres now holds routing as well
    as keys, budgets and spend. Losing it means the proxy no longer knows what to
    proxy, not merely who may call it. Virtual keys are stored hashed and shown
    once at mint, so recovery also means re-minting every key and reconfiguring
    every consumer.

With fleet state in LiteLLM there is one artifact rather than two, and nothing
outside the database to reconstruct from. The GPU boxes keep serving from their
local assignment, so a lost database does not stop inference — but nothing can
re-fetch, re-route or re-authenticate until it is restored.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions