Backup e restauração

Uma vez que sua instância estiver em uso, crie um backup antes de atualizar ou mover servidores. Primeiro pedido.

SubLane pode exportar uma instância em execução, verificar uma cópia de segurança e restaurá- la num novo directório. Tanto a linha de comandos como a Configurações do sistema → Backup e restauração usar a mesma validação de arquivo e restaurar a implementação. A recuperação nunca substitui a instância em execução; a mudança para dados restaurados é um reinício explícito do operador.

O que está incluído

Os novos backups são arquivos age binários criptografados com senha. Após descriptografar, o arquivo gzip/tar contém:

• sublane.db: uma coerência SQLite instantâneo, incluindo dados WAL comprometidos.
• credentials.key: a chave de criptografia correspondente para credenciais de assinatura e chaves de gateway recuperáveis.
• manifest.json: versão de formato, tempo de criação, SubLane build version, schema version, file sizes e checksums SHA-256.

Usuários, senhas, API chaves, contas de assinatura, conjuntos, permissões, catálogos, configurações, registros de pedidos, resumos de uso, recargas e registros de afinidade estão incluídos. As sessões de navegadores são capturadas no backup, mas limpas em um diretório restaurado. Browser- local theme/language choices, process environment, implantation files and pendente in- memory OAuth As tentativas não estão incluídas.

Novas exportações exigem uma senha de 12 a 128 caracteres. O SubLane não a armazena. Guarde-a separadamente: perdê-la impede a recuperação do backup criptografado. Arquivos .tar.gz antigos sem criptografia continuam verificáveis e restauráveis sem senha, mas contêm chaves legíveis e devem ser mantidos em local privado.

Linha de comando

Execute os comandos de um diretório com espaço livre suficiente para o instantâneo do banco de dados e arquivo compactado:

mkdir -p backups
./bin/sublane backup --password-stdin --output ./backups/team.sublane-backup.tar.gz.age < /secure/backup-password
./bin/sublane backup verify --password-stdin --input ./backups/team.sublane-backup.tar.gz.age < /secure/backup-password
./bin/sublane restore --password-stdin --input ./backups/team.sublane-backup.tar.gz.age --data-dir ./data-restored < /secure/backup-password

backup reads SUBLANE_DATA_DIR ou ./data, com um opcional --data-dir Ativar. restore Necessita sempre de uma nova pasta explícita; até mesmo uma pasta vazia existente é rejeitada. A pasta- pai deverá existir. Os ficheiros de arquivo existentes e as pastas de restauração nunca são substituídos. Os comandos bem- sucedidos imprimem uma JSON resultado com a operação, caminho e metadados de backup. sublane --help lista os comandos.

Os comandos de manutenção não iniciam o HTTP servidor, SDK executores, OAuth, ou verificações automáticas de lançamento, e não dependem do endereço do servidor/configuração pública-URL. Eles têm um prazo de quinze minutos e respondem ao SIGINT/SIGTERM. Os instantâneos do banco de dados são limitados a 4 GiB e o arquivo IO usa buffers limitados. Permitir espaço em disco para extração e migrações ao verificar ou restaurar, além do próprio arquivo.

Após uma restauração bem sucedida:

1. Parar a corrente SubLane serviço.
2. Mantenha o diretório de dados original intacto.
3. Iniciar SubLane com o diretório restaurado:

SUBLANE_DATA_DIR=./data-restored ./bin/sublane

4. Entre novamente e verifique os usuários, pools, chaves e estados de conta esperados antes de retomar o tráfego da equipe.

O diretório original está disponível para o rollback ao parar SubLane e comutação SUBLANE_DATA_DIR voltar. Não execute duas instâncias de gateway contra a mesma pasta de dados. Restaurando todos os estados armazenados para o instantâneo: não estão incluídas as revogações posteriores da chave, as alterações de senha e os novos registros. Um provedor de assinatura pode ter invalidado os tokens de atualização antigos, uma vez que o backup; reautoriza contas afetadas quando necessário. Verificação verifica a descriptografia e integridade local sem contatar os provedores.

Interface Web

Apenas os administradores habilitados podem usar a página ou seus endpoints. Mutações requerem a origem exata do navegador e exportam novamente a sessão de administrador após preparar o arquivo.

• Obter cópia de segurança cria e baixa um arquivo completo enquanto a instância permanece disponível.
• Verificar backup verifica o ficheiro seleccionado e mostra a sua hora de criação, SubLane versão e tamanho do banco de dados.
• Preparar a restauração envia e valida o arquivo novamente, então cria <current data directory>/restore-ready. A página mostra o caminho completo e reinicia as instruções. A instância atual continua rodando com seus dados originais até que o operador mude de diretório.

Um existente restore-ready O caminho bloqueia outra preparação. Inspecione- a no servidor ou use o CLI com um novo alvo diferente. Nenhuma pasta poderá ser sobrescrita através da Web API. Se os dados de recuperação foram preparados, mas a gravação de auditoria ao vivo falhou, o diretório é mantido e a página relata a falha de auditoria; inspecione-o antes de tentar novamente.

Os uploads e downloads da Web são limitados a 256 MiB de dados compactados; backups maiores requerem o CLI. Uma operação de exportação/verificação/restore é executada de uma vez por servidor. Envio, processamento e download têm prazos limitados. Os arquivos temporários são removidos após a conclusão, falha ou cancelamento normal. Um processo forçado pode deixar uma perda de energia privada .sublane-backup-* pasta; remova as pastas de encenação restantes apenas quando nenhuma operação de backup estiver em execução.

Exportações e restaurações preparadas são auditadas sem gravar o conteúdo do arquivo, nomes de arquivos, caminhos do sistema de arquivos ou credenciais. Cache-Control: no-store. Os streams de página enviam do arquivo selecionado; o navegador recebe o arquivo baixado como uma bolha temporária e libera sua URL após iniciar o download.

Exemplo de controles de backup e restauração do navegador:

Docker Compose

Para exportar e verificar dentro do recipiente em execução:

docker compose -f docker.compose.yaml exec sublane sh -c 'mkdir -p /data/backups'
docker compose -f docker.compose.yaml exec -T sublane sublane backup --password-stdin --output /data/backups/team.sublane-backup.tar.gz.age < /secure/backup-password
docker compose -f docker.compose.yaml exec -T sublane sublane backup verify --password-stdin --input /data/backups/team.sublane-backup.tar.gz.age < /secure/backup-password
docker compose -f docker.compose.yaml cp sublane:/data/backups/team.sublane-backup.tar.gz.age ./team.sublane-backup.tar.gz.age

Para recuperação, copie um backup em um local privado gravável visível dentro do recipiente, em seguida, prepare um diretório separado:

docker compose -f docker.compose.yaml exec -T sublane sublane restore --password-stdin --input /data/backups/team.sublane-backup.tar.gz.age --data-dir /data/restore-ready < /secure/backup-password

A ação de restauração web produz o mesmo alvo. Para ativá- lo, crie um local Compose sobreposição, por exemplo docker.compose.restore.yaml:

services:
  sublane:
    environment:
      SUBLANE_DATA_DIR: /data/restore-ready

Em seguida, pare o processo original e comece com o cancelamento:

docker compose -f docker.compose.yaml stop sublane
docker compose -f docker.compose.yaml -f docker.compose.restore.yaml up -d

Para um recipiente já parado, utilizar docker compose -f docker.compose.yaml run --rm --no-deps sublane ... em vez de exec para executar os comandos de manutenção contra o volume de dados nomeado. Mantenha o sobreposição selecionada nos comandos de implantação subsequentes. Não remova o volume nomeado durante este procedimento.

Validação e comportamento de falha

Verificação verifica entradas e tamanhos exatos do arquivo, SHA-256 digests, integridade gzip, a versão consolidada suportada do esquema, SQLite Integridade e chaves estrangeiras, registros de credenciamento limitados, e descriptografia de credenciais de conta e criptografados API chaves. As conexões de validação também cap individual SQLite valores e instruções SQL em 1 MiB. Symlinks, traversal caminho, duplicar/arquivos inesperados, arquivos em falta, arquivos truncados e esquemas futuros desconhecidos são rejeitados. Esquemas de desenvolvimento mais antigos não são aceitos por esta compilação pré-lançamento.

Restaurar fecha e sincroniza seu banco de dados/chave preparado antes de publicar todo o novo diretório com uma operação sem substituição atômica. Linux e macOS requerem suporte ao sistema de arquivos para essa operação; uma operação não suportada falha sem cair para trás para uma sobrescrita. Nenhuma tabela de banco de dados extra ou migração de esquema é introduzida pelo suporte de backup. SQLite criação de instantâneos usa o SQLite Cópia de segurança 'online' API através do driver Go preso, em vez de copiar um arquivo de banco de dados ao vivo.

Utilização application/gzip ou application/octet-stream para uploads. Arquivos inválidos retornam 400, um destino existente retorna 409, uploads superdimensionados retornam 413, e um slot de operação ocupado retorna 429 com Retry-After. Armazenamento e outras falhas operacionais retornam erros 503 higienizados.

credentials.key · Senha do backup

Pare a instância existente, copie sua chave original para um local privado fora do diretório de dados e defina os direitos do usuário do serviço. Remova a cópia antiga apenas após verificar a inicialização e um backup criptografado.

SUBLANE_CREDENTIALS_KEY_FILE: Arquivo privado de chave opcional fora do diretório de dados; sem configuração, mantém o local atual.

Se a chave for armazenada separadamente, mova o credentials.key restaurado para um novo local privado fora do diretório de dados e atualize SUBLANE_CREDENTIALS_KEY_FILE antes de reiniciar. Não sobrescreva a chave da instância original.

Use de 12 a 128 caracteres. Guarde a senha separadamente; ela não pode ser redefinida se for perdida. Obrigatória para backups criptografados. Deixe em branco para arquivos antigos sem criptografia.

--key-file FILE · --password-stdin · scrypt: 18 (~256 MiB)

Leia a senha com --password-stdin de um arquivo privado de uma linha com permissões 0600; não a coloque em argumentos ou variáveis de ambiente.

A interface envia multipart/form-data, com password antes de file. Uploads brutos antigos continuam aceitos sem senha.

Migração automática da chave no Compose

O repositório da aplicação fornece scripts/separate-key.sh para implantações Compose existentes com SubLane v0.12.0+. Salve e revise o script antes de executá-lo no host Docker. Primeiro exporte e verifique um backup de recuperação criptografado com senha.

sudo bash scripts/separate-key.sh --dir /srv/sublane --key-dir /srv/sublane-secrets

--dir identifica a implantação existente com docker.compose.yaml e seu .env opcional. --key-dir deve ser um novo caminho absoluto em armazenamento persistente do host, fora do ponto de montagem real dos dados e do diretório de recuperação, com o diretório pai já existente. Caminhos ASCII comuns, incluindo espaços, são aceitos. É necessário Linux local com Docker rootful sem remapeamento userns nem SELinux, Compose, Bash, jq e GNU coreutils. O serviço saudável deve se chamar sublane e seu diretório de dados deve ser a raiz de um bind mount ou volume nomeado gravável. Compose deve usar dois espaços para indentar os serviços, um mapeamento em bloco para environment e uma lista em bloco para volumes. Estruturas não suportadas são recusadas antes de parar o serviço.

O script verifica projeto, imagem, montagem, permissões privadas, tamanho de 32 bytes e hash da chave original. Preserva o texto do Compose e a interpolação de variáveis e compara a configuração normalizada. O novo diretório do host permanece de propriedade de root com modo 0700; somente o arquivo de chave 0600, pertencente ao UID/GID do serviço, é montado como somente leitura. As permissões do serviço não são elevadas.

Antes da troca, depois dela e após remover a chave antiga, cria e verifica um backup temporário criptografado com uma nova senha aleatória. A área temporária fica fora do diretório de dados e é removida ao terminar. Reserve espaço em disco e memória suficientes para a KDF do backup. Essas verificações não guardam um backup de recuperação. A cópia antiga só é removida após aprovação da configuração, da integridade do serviço, do hash e da validação das credenciais; uma nova recriação e verificação confirma a independência do arquivo antigo.

Erros ou sinais capturáveis após o início da troca provocam uma tentativa de reversão. Também é possível reverter após uma migração bem-sucedida:

sudo bash scripts/separate-key.sh --dir /srv/sublane --rollback

Os registros privados de recuperação permanecem em /srv/sublane/.key-migration. A reversão restaura a configuração original e a chave correspondente, recria o serviço original e o verifica. Ela se recusa a sobrescrever alterações posteriores na configuração ou no ambiente, ou uma chave diferente, e nunca rebaixa a imagem ou o banco de dados. A chave externa e os registros continuam privados após a reversão. Uma nova migração não sobrescreve registros ou destinos existentes: arquive os registros verificados com segurança e escolha um novo diretório de chave antes de tentar novamente.

O script compartilha .update-lock com o instalador; não execute outras operações de implantação ao mesmo tempo. Após encerramento forçado ou falta de energia, confirme que nenhuma migração ou atualização está em execução, remova apenas o .update-lock vazio abandonado e use --rollback. Se não for possível verificar a reversão, o material de chave de recuperação e um operation.log privado são mantidos. Preserve ambos os diretórios até concluir a recuperação. Os backups guardados e suas senhas devem continuar separados.

Backups criptografados automáticos

Ative as configurações de implantação abaixo. Diretório privado (0700), senha independente de 12–128 caracteres em arquivo regular privado (0600, sem link simbólico), separado dos dados e backups. A senha é relida em cada execução.

export SUBLANE_BACKUP_DIR=/srv/sublane-backups
export SUBLANE_BACKUP_PASSWORD_FILE=/secure/sublane/backup-password
export SUBLANE_BACKUP_INTERVAL=24h
export SUBLANE_BACKUP_KEEP=7

Executa ao iniciar e aguarda o intervalo após cada tentativa. Verifica totalmente o novo arquivo antes de rotacionar nomes reservados scheduled-; preserva arquivos manuais e o novo verificado. Resultados nos logs do serviço. Sem upload remoto ou formulário de agendamento; desativado na demonstração.

SUBLANE_BACKUP_INTERVAL: 1h–720h (default 24h). SUBLANE_BACKUP_KEEP: 1–365 (default 7).

Use um destino de backup exclusivo para cada instância.

A opção SUBLANE_BACKUP_WEBHOOK_URL envia a um destino HTTPS público um evento JSON backup_failure limitado por tentativa malsucedida. Esse destino do operador é da instância, separado dos alertas do espaço; falhas de envio são registradas.

No Docker use caminhos do contêiner e monte o arquivo privado e o diretório dedicado gravável em uma substituição Compose local, dando acesso ao usuário do serviço. O tmpfs /tmp padrão tem 64 MiB. Verificações maiores exigem um volume privado gravável separado e TMPDIR na substituição.