Operação

A operação do dia a dia de um TrustBridge implantado: o que monitorar, o que ler nos logs, como um reinício e uma atualização se comportam, como manter a frota numa versão que o Servidor aceita e a manutenção recorrente que uma implantação exige.

Saúde e monitoramento

Probe	O que comprova	Para que usar
GET /healthz	Uma ida e volta ao SQL. Healthy (200) ou Unhealthy (503), e nada mais no corpo. Anônimo, não auditado.	Monitoramento de disponibilidade e alertas. Um 503 é um container no ar com um banco de dados fora do ar.
GET /	O container está vivo. Responde 200 mesmo sem o banco de dados.	Um gatilho de reinício, onde a plataforma tiver um (o Health check do App Service).
Entrar em /admin	O caminho que uma requisição real percorre, passando pelo banco de dados.	A verificação depois de toda implantação e atualização.

O /healthz não informa nada sobre a frota: um Servidor sem nenhuma estação de trabalho conectada está Healthy. A presença de uma máquina é assunto da tela da frota.

O Servidor inicia e continua no ar com o banco de dados inacessível depois da inicialização, para que uma instabilidade momentânea do banco não vire uma indisponibilidade que uma pessoa precise resolver. Enquanto o banco de dados está fora, a porta de entrada responde 200, o contrato falha e o cofre fica fechado. Crie alertas sobre o /healthz, não sobre o container.

Como o Servidor aplica o próprio schema na inicialização, um container em execução já comprovou que acessou o SQL pelo menos uma vez; um banco de dados inacessível na inicialização resulta numa inicialização recusada depois de cerca de noventa segundos.

O que o console administrativo informa

• A faixa de status, no topo de toda página administrativa, conta as estações de trabalho conectadas, as máquinas cujo protocolo o Servidor não aceita mais (N exigem atualização), as sessões ativas, as assinaturas e as falhas das últimas 24 horas e os certificados que vencem em 30 dias. Cada chip abre a tela que resume. N falhas (24 h) abre a Trilha de Auditoria filtrada nas falhas desde o momento em que a contagem começou; é o caminho mais curto entre "algo está errado" e as linhas que dizem o quê.
• Um banner em todas as páginas administrativas significa uma de três coisas: a licença da PKI do Servidor foi recusada, então nada na frota nem no cofre consegue assinar (renove-a); as gravações de auditoria estão caindo para o Log do Servidor; ou as ACs de teste da Lacuna são confiáveis.
• Por que uma estação de trabalho se desconectou está na linha workstation.disconnect dela, e ao lado de cada desconexão no painel da máquina na tela da frota: timed-out (o Servidor deixou de ouvi-la; veja Workstations:ClientTimeout), closed, revoked, returned-to-queue, server-stopping ou error, com o transporte que ela usava. Um closed em LongPolling também pode ser uma máquina que ficou em silêncio: o long polling não sofre timeout, e um proxy que não transporta WebSockets é o motivo mais comum para uma máquina estar nele.

Avisos que merecem um alerta

Linha do Log do Servidor, em Warning	O que significa
Workstation … holds a candidate certificate for this session but is connected at protocol 4 …	Uma máquina ainda no Workstation 1.4.x foi ignorada na criação de uma sessão. Ela conta como offline até rodar a 1.5.0. Veja Ordem de atualização.
Workstation … has given N PIN Proof(s) for CPF … that did not check …	Uma máquina esgotou o seu limite de provas com falha para um titular (Sessions:MaxPinFailures dentro de Sessions:PinFailureWindow). Nada é pedido a ela para esse CPF até as falhas saírem da janela. Registrado na auditoria como pin.proof-budget-spent.
The Certificate Vault has tried N password(s) for CPF … that opened nothing …	O mesmo limite, esgotado pelo cofre. Também registrado como pin.proof-budget-spent, com Certificate Vault como nome do titular.
Passwords are switched off on this Server's admin console …	Registrado em toda inicialização enquanto Admin:CertificateSignIn:Required está ligado. Conta as contas habilitadas sem CPF vinculado e quantas delas são de Administradores. Quando esse número chega ao número de Administradores habilitados, ninguém consegue administrar a plataforma.
Forwarded headers: honoured from whoever connects …, and this Server is not on App Service	Uma implantação Docker que ainda usa ASPNETCORE_FORWARDEDHEADERS_ENABLED. Cite o proxy em ForwardedHeaders:TrustedProxies e remova a variável.
… pings every 00:00:15, but Workstations:ClientTimeout is …	Uma máquina envia pings com menos frequência do que o timeout permite, então é desconectada e se reconecta sem parar.

Um limite esgotado não é o bloqueio de PIN do titular: um PIN errado custa à própria máquina do titular uma prova com falha por certificado dele que ela guarda, então uma máquina pode ser ignorada antes de o bloqueio disparar. Os dois se resolvem conforme as falhas saem da janela.

A trava do cofre

Num Servidor com Vault:Enabled, as verificações de inicialização do cofre leem o banco de dados. Quando o Servidor sobe antes de o banco de dados responder, o cofre fica travado fechado, em vez de o host recusar a inicialização:

warn: TrustBridge.Server.Common.Vault.VaultReadiness[0]
      The Certificate Vault is on, but its start-time checks could not read the database, so the
      vault is closed until they have run. Nothing will be signed with a certificate this Server
      holds and nothing new will be imported until then; the checks are retried at the first
      attempt to use it (ADR-0024 §8).

Um cofre fechado é um Servidor com aparência saudável que recusa toda assinatura com um certificado guardado no servidor e toda importação, enquanto o nível das estações de trabalho funciona normalmente. As verificações são repetidas na primeira tentativa de usar o cofre, e um banco de dados que voltou as conclui com o cofre aberto. O que um cofre fechado nunca pode fazer é gerar uma chave nova, o que deixaria órfão tudo o que está armazenado: é por isso que a trava existe.

Leitura dos logs

A saída do console é o registro. Envie-a para um lugar com a retenção que você escolheu: o logging driver do container no Docker, o Application Insights ou um workspace do Log Analytics no App Service. O arquivo rotativo em /tmp/trustbridge-logs alimenta a tela Log do Servidor do console administrativo e é uma conveniência, não uma cópia a guardar.

Estas categorias trazem as linhas que um operador deve reconhecer, todas visíveis no nível padrão:

Linha	Categoria	Quando
Quais migrações foram aplicadas, ou por que o schema foi recusado	…Persistence.SchemaUpgrade	Toda inicialização
Qual Protetor do Chaveiro está selando, o thumbprint dele e quantos aposentados estão legíveis	…KeyRings.KeyRingPosture	Toda inicialização
Se o cofre está desligado, aberto ou travado fechado	…Vault.VaultReadiness	Toda inicialização, e quando a trava se abre
Em quais proxies reversos o Servidor confia para o endereço de quem chama, numa linha que começa com Forwarded headers:	…Http.TrustedProxies	Toda inicialização
Quantas contas não têm CPF vinculado enquanto as senhas estão desligadas	…Admin.CertificateSignInPosture, em Warning	Toda inicialização com Admin:CertificateSignIn:Required ligado
Uma linha de auditoria não conseguiu chegar ao banco de dados, com a própria linha	…Audit.AuditLog, em Critical	Sempre que o banco de dados recusa uma gravação
A licença do PKI SDK foi recusada: vencida, corrompida ou não é uma licença	TrustBridge.Pki.Validation.LacunaPkiRuntime, em Critical	Toda inicialização, com ou sem cofre, e quando uma licença vence com o Servidor em execução
Os overrides do Administrador não puderam ser relidos depois da etapa do schema	…Persistence.SchemaGate	Uma inicialização em que a tabela de configurações não respondeu
Uma máquina ignorada na criação de uma sessão: no protocolo 4, ou com o limite de provas com falha esgotado	…Sessions.CreateSession.Handler, em Warning	Sempre que acontece

Toda resposta HTTP traz um X-Correlation-Id, e toda linha de log gravada durante o atendimento dela traz o mesmo id, assim como as linhas da Trilha de Auditoria que ela gerou. A reclamação de um cliente, uma linha de log e uma linha de auditoria se encontram por esse id.

O fallback da auditoria faz parte da sua retenção de logs, e não dos seus backups. Uma linha de auditoria que o banco de dados não aceitou é gravada no Log do Servidor no nível Critical e em nenhum outro lugar, e o console administrativo mostra um alerta. A trilha tem um buraco exatamente onde o banco de dados estava fora; as linhas Critical são o que o preenche.

A Trilha de Auditoria

A retenção é Audit:RetentionDays (365), que aceita override na tela Configurações e usuários. Uma limpeza diária exclui as linhas mais antigas. Ajuste-a ao prazo de contestação da implantação. A limpeza sobre uma tabela AuditEvents grande também é o que torna alguma migração ocasional demorada, e é para isso que servem o WEBSITES_CONTAINER_START_TIME_LIMIT=1800 no App Service e o prazo de trinta minutos por comando.

Relatórios e consultas escritos diretamente sobre o banco de dados precisam de duas mudanças desde o Servidor 1.11.0:

• certificate.encoding-dropped e certificate.announcement-refused gravam uma linha por snapshot, e não uma por certificado. Os detalhes passam a ser { count, entries: [...] }. As linhas gravadas antes da 1.11.0 mantêm os campos planos, então tudo o que interpreta esses detalhes precisa ler os dois formatos. O cpf da linha só é preenchido quando todas as entradas citam o mesmo titular; uma linha que cobre vários é encontrada pela máquina, não pelo CPF.
• Workstations.EnrolledAt agora é Workstations.FirstSeenAt. Só o nome da coluna mudou; o console administrativo já dizia "Vista pela primeira vez".

Reinícios e atualizações

Uma única instância, então todo reinício é uma indisponibilidade visível de um ou dois minutos. O que sobrevive:

	Sobrevive a um reinício do Servidor
Conexões das estações de trabalho	As máquinas se reconectam sozinhas, com backoff
Sessões de Assinatura vinculadas a estações de trabalho	Sim, intactas: o PIN em que se apoiam está em cache na máquina
Sessões de Assinatura vinculadas ao cofre	Não. Terminam como Stranded; os clientes recebem SESSION_EXPIRED e criam novas com o mesmo PIN
Logins de Administradores	Sim: o chaveiro das sessões web está no banco de dados
Requisições de assinatura em andamento	Não; falham de forma que podem ser repetidas. Uma Operação de Assinatura que ficou em Pending é encerrada por uma varredura como Failed, com RUN_STRANDED
Overrides de configuração do Administrador	Sim

No App Service, a plataforma reinicia containers para a própria manutenção, então uma cadência de reinícios que não é sua fica visível para a assinatura com o cofre. Deixe DOCKER_ENABLE_CI desligado e faça deploy de forma deliberada.

Atualizar o Servidor é usar uma nova tag de imagem: docker compose pull && docker compose up -d, ou uma nova imagem no App Service, por exemplo trustbridge-server:1.13.0. A nova imagem aplica as próprias migrações na inicialização e as cita no log. Com Database:MigrateOnStart=false, aplique-as antes, ou a nova imagem não inicia.

Faça backup do banco de dados antes de toda atualização: é o único caminho de volta. Toda release do Servidor da 1.9.0 à 1.13.0 migra o schema, e uma imagem mais antiga não inicia sobre um banco de dados que uma mais nova migrou. Reverter, portanto, é restaurar o backup de antes da atualização e implantar a imagem anterior, nunca só trocar a tag. Uma frota que já passou para um protocolo de estação de trabalho mais novo também não consegue se conectar ao Servidor mais antigo.

Atualizando a partir do Servidor 1.6.x: defina Certificates:Validation:License antes. Todo Servidor desde a 1.7.0 precisa da licença da PKI, com ou sem cofre, e não inicia sem ela.

Ordem de atualização: primeiro o Servidor, depois a frota

O Servidor aceita duas versões do protocolo das estações de trabalho: a dele e a anterior. Uma máquina num protocolo mais antigo é recusada com update required; uma num protocolo mais novo é recusada com update the Server first. As duas recusas ficam registradas na linha da máquina na tela da frota e na Trilha de Auditoria como um workstation.connect com falha, e uma máquina recusada não assina nada.

Servidor	Aceita os protocolos	Versões do Workstation que aceita
1.6.x	1–2	1.0.x
1.7.0 – 1.8.0	2–3	1.0.x, 1.1.0 – 1.3.0
1.9.0 – 1.12.0	3–4	1.1.0 – 1.3.0, 1.4.x
1.13.0	4–5	1.4.x (conecta, mas não atende sessões novas), 1.5.0

O Workstation 1.0.x fala o protocolo 2, da 1.1.0 à 1.3.0 o protocolo 3, da 1.4.0 à 1.4.2 o protocolo 4, e a 1.5.0 o protocolo 5.

Dentro de uma janela de protocolos, a regra é: atualize primeiro o Servidor, depois as estações de trabalho, com no máximo uma release de diferença. Uma máquina à frente do seu Servidor não consegue se conectar: o Servidor mais antigo a recusa com update the Server first, não lhe entrega a licença da PKI, e todo certificado dessa máquina aparece como UNTRUSTED no Tray App até o Servidor ser atualizado. Um Servidor à frente de uma máquina que ainda está na janela dele é suportado.

O protocolo 5 é a exceção: o Servidor 1.13.0 e o Workstation 1.5.0 andam juntos. No protocolo 5 o Servidor não envia mais o PIN da aplicação cliente a nenhuma estação de trabalho: ele desafia cada máquina que tem um certificado candidato e confere a Prova de PIN (PIN Proof) com que a máquina responde. Uma máquina no protocolo 4 (Workstation 1.4.x) ainda se conecta ao Servidor 1.13.0, recebe a licença, busca as Autoridades Certificadoras Confiáveis, anuncia os certificados, assina para as sessões já vinculadas a ela e pode receber a oferta de uma versão. Ela nunca recebe um desafio de PIN nem uma solicitação de PIN, então, para a criação de sessões, conta como offline. Um titular cujas máquinas estão todas ainda na 1.4.x recebe 422 WORKSTATION_OFFLINE até que uma delas seja atualizada, e o Servidor registra um Warning cada vez que ignora uma máquina assim. A atualização é, portanto, uma indisponibilidade para todo titular cujas máquinas forem atualizadas com atraso. Uma máquina na 1.3.0 ou anterior é recusada de vez.

Uma atualização para o Servidor 1.13.0, na ordem:

1. Faça backup do banco de dados.
2. Planeje as máquinas que o Servidor não consegue atualizar: as que estão no Workstation 1.3.0 ou anterior, e as cuja Diretiva de Grupo desliga as atualizações pelo Servidor. Elas precisam do Workstation 1.5.0 instalado à mão ou por Diretiva de Grupo, na mesma janela de manutenção, porque uma máquina na 1.5.0 não se conecta a um Servidor anterior à 1.13.0.
3. Atualize o Servidor.
4. Envie o TrustBridge-Workstation-1.5.0-x64.msi na tela Versões da Estação de Trabalho e ofereça-o com Entregar a todas ainda não atualizadas… na tela Estações de Trabalho. O envio precisa esperar a atualização: um Servidor recusa uma versão que fala um protocolo mais novo que o dele.
5. Acompanhe a coluna Versão do serviço da tela da frota e as linhas Warning que citam máquinas no protocolo 4, até toda máquina rodar a 1.5.0. Depois, se quiser que máquinas que sumiram apareçam como offline mais cedo, reduza Workstations:ClientTimeout para 00:00:15: toda máquina que consegue se conectar à 1.13.0 envia pings com frequência suficiente para isso.

Nada muda para as aplicações cliente: o SignSession Contract não mudou e o PIN continua chegando em POST /v1/sessions. Agora ele não passa do Servidor.

Atualizar as estações de trabalho à mão é instalar um MSI mais novo sobre o antigo, sem propriedades. Veja Instalação das estações de trabalho. A partir do Workstation 1.4.0, uma máquina também pode receber uma versão do seu Servidor: veja Atualização da frota pelo Servidor.

Atualização da frota pelo Servidor

Desde o Servidor 1.9.0, um Administrador pode entregar uma Versão da Estação de Trabalho à frota pelo console administrativo, e uma máquina com o Workstation 1.4.0 ou posterior a instala sozinha.

1. Envie a versão na tela Versões da Estação de Trabalho: o MSI assinado, de até 256 MB. O Servidor lê do próprio arquivo a versão, o protocolo que ela fala e o assinante, e a armazena no banco de dados. Ele recusa, citando o motivo e sem armazenar nada, um arquivo que não é um MSI, um pacote não assinado, um assinado por um certificado que o Publisher Pin dele não lista, uma versão que não são três números, um pacote que não declara protocolo (toda versão anterior ao Workstation 1.3.0), um protocolo fora da janela do Servidor e uma versão já armazenada. Cada recusa é uma linha admin.workstation-release-uploaded com falha na Trilha de Auditoria. No App Service, o envio é uma única requisição e precisa terminar dentro do timeout de quatro minutos do front end.
2. Ofereça-a na tela Estações de Trabalho: Oferecer versão… para as máquinas selecionadas, ou Entregar a todas ainda não atualizadas…, que lista toda máquina que a versão alcança para você desmarcar o que quiser antes de confirmar. Uma oferta só alcança uma máquina Admitida, no protocolo 4 ou posterior, abaixo da versão, cujo Publisher Pin lista o assinante da versão e cuja Diretiva de Grupo deixa as atualizações ligadas. As demais aparecem com o motivo e mantêm o que tinham.
3. Cada máquina a instala sozinha: depois de uma espera aleatória de até dez minutos, baixa o pacote do Servidor, verifica-o, espera até não haver assinatura em andamento nem solicitação de PIN aberta, e o instala. Ela informa o resultado no próximo handshake, como installed, failed (com o código de saída do msiexec e o final do log dele) ou refused (citando a verificação que falhou). Cada resultado é uma linha workstation.update-installed, -failed ou -refused na Trilha de Auditoria.

Uma versão que falhou ou foi recusada não é tentada de novo até ser oferecida de novo. Corrija a causa e ofereça a mesma versão à máquina outra vez, ou use Entregar a todas ainda não atualizadas…, que oferece de novo a toda máquina que seleciona. Uma máquina que estava offline quando a versão foi oferecida de novo tenta no próximo handshake. Uma instalação que o Windows Installer estava ocupado demais para iniciar (código 1618) é repetida pela própria máquina cerca de quinze minutos depois.

Retirar a oferta interrompe toda máquina que ainda não começou a instalação: Retirar oferta para as máquinas selecionadas, Retirar de todas na tela Versões da Estação de Trabalho para uma versão. Uma versão oferecida a alguma máquina não pode ser excluída até as ofertas serem retiradas. Uma máquina que já instalou uma versão continua nela.

Quem o Servidor não alcança aparece na tela Estações de Trabalho: Atualizações desativadas por diretiva para uma máquina cuja diretiva Receber atualizações do Servidor TrustBridge está desativada, e Precisa de atualização manual para uma cuja versão não recebe atualizações do Servidor. O Workstation 1.3.0 e anteriores nunca recebem uma versão por esse caminho. Essas máquinas recebem a versão à mão ou por Diretiva de Grupo.

Os downloads têm um limite próprio, WorkstationReleases:MaxConcurrentDownloads (20); uma máquina acima dele é informada de quando voltar. Eles não contam para o throttling das aplicações cliente, então uma distribuição não faz o contrato responder 429.

Rotação do Protetor do Chaveiro

A rotação é aditiva: um protetor novo sela as chaves novas e nunca re-cifra o que já está armazenado.

1. Mova o base64 do protetor que está saindo para KeyRingProtector__RetiredCertificates__0__Certificate (com …__0__CertificatePassword ao lado, se ele tiver senha). Um segundo protetor aposentado usa o índice 1, e assim por diante.
2. Coloque o novo em KeyRingProtector__Certificate.
3. Reinicie. A linha KeyRingPosture deve passar a citar o novo thumbprint e 1 retired protector(s).
4. Guarde o PKCS#12 antigo nos seus backups, permanentemente. Não existe um momento em que a rotação "termina".

Nunca coloque uma entrada aposentada vazia num template: uma entrada que resulta numa string vazia recusa a inicialização.

Renovação da licença do PKI SDK

A licença fica só no Servidor, e o Servidor a entrega à frota inteira. Toda estação de trabalho Admitida recebe a licença do Servidor ao se conectar e a mantém apenas em memória. Não há nada a configurar nas máquinas: nenhuma propriedade do MSI e nenhum valor de Diretiva de Grupo traz uma licença.

A licença do Lacuna PKI SDK vence numa data, e nada avisa antes disso. Depois que ela vence, o Servidor registra uma linha Critical, toda página administrativa mostra um banner, e nada na frota nem no cofre consegue assinar: os certificados passam a informar UNTRUSTED, e a criação de sessões é recusada com CERT_NOT_ACTIVE. Leia o vencimento no arquivo e coloque-o no calendário que acompanha as renovações de certificados:

base64 -d license.base64 | grep -o '<Expiration>[^<]*'

Para renovar, substitua Certificates__Validation__License pelo novo base64 e reinicie o Servidor: no Docker, troque o PKI_LICENSE no .env e recrie o container; no App Service com uma referência do Key Vault, crie uma nova versão do secret e reinicie. O reinício é o que chega à frota: toda máquina conectada se reconecta e aplica a nova licença, e uma máquina que estava offline a recebe quando se conectar de novo.

Rotação da Installer Key

Só para uma implantação que gerou uma Installer Key própria. O Servidor aceita todas as chaves que lista, então uma troca é uma distribuição gradual, e não uma virada num dia marcado: adicione a nova chave pública ao lado da antiga em Admission:InstallerKeys, reinicie o Servidor, aponte o INSTALLER_KEY das máquinas para a nova por um reparo silencioso, no ritmo de cada uma, e então remova a entrada antiga e reinicie de novo.

Rotação das chaves de API

Emita uma nova chave para a Aplicação Cliente na tela Aplicações Cliente, implante-a no cliente e depois revogue a antiga. Todas as chaves aceitas de uma aplicação são equivalentes, então a troca é invisível para as sessões em andamento.

Gerenciamento da frota

• Uma máquina que nunca aparece na fila quase sempre tem um problema de URL ou de cadeia TLS; leia primeiro o log Aplicativo do Visualizador de Eventos dela. Veja Instalação das estações de trabalho.
• Uma máquina desativada deve ser revogada na tela da frota, tenha sido desinstalada ou não. A revogação não depende da cooperação da máquina.
• Uma máquina reinstalada é uma máquina nova, com uma impressão digital nova, e chega de novo à fila. Uma atualização ou um reparo continua sendo a mesma máquina.
• Uma máquina recusada com update required roda uma versão mais antiga que a janela do Servidor: no Servidor 1.13.0, o Workstation 1.3.0 ou anterior. Instale nela a versão atual à mão ou por Diretiva de Grupo.
• Uma máquina que mostra Atrasada na coluna de Autoridades Certificadoras Confiáveis se reconecta e busca o conjunto de novo sozinha.
• Desvio de relógio. Uma máquina cujo relógio está mais de Workstations:ClockSkewTolerance (60 s) fora não consegue se conectar, e o log do Servidor a cita em Warning: A workstation assertion was refused: Expired ou NotYetValid, com o thumbprint da chave da máquina e a diferença, positiva quando a máquina está atrasada em relação ao Servidor e negativa quando está adiantada. A solução é a sincronização de horário.

Os diretórios temporários

O Servidor grava três diretórios em /tmp dentro do container, e nada mais:

Caminho	Contém	Se for perdido
/tmp/trustbridge-pki	O cache do PKI SDK com os emissores e LCRs baixados, e a licença entregue ao SDK como arquivo	Nada. A validação baixa de novo o que precisa, a cerca de 1,15 s por passagem em vez de 140 ms
/tmp/trustbridge-logs	O arquivo de log rotativo que a tela Log do Servidor lê	Nada. Toda linha foi gravada primeiro no console
/tmp/trustbridge-releases	Uma cópia de cada Versão da Estação de Trabalho armazenada, de onde saem os downloads da frota, e um envio enquanto o Servidor o lê	Nada. Cada cópia é refeita a partir da linha da versão no banco de dados no próximo download

Um sistema de arquivos somente leitura é tolerado, com duas exceções. O SDK só lê uma licença a partir de um arquivo, então um container sem nenhum diretório temporário gravável inicia um Servidor cuja licença o SDK nunca leu: nada consegue assinar, e o console administrativo avisa. E um envio na tela Versões da Estação de Trabalho é gravado em trustbridge-releases antes de ser lido, então, onde esse diretório não pode ser gravado ou está cheio, todo envio é recusado com o motivo e o log do Servidor cita o diretório. Os downloads continuam funcionando sem ele, lidos do banco de dados.

Monte um tmpfs sobre /tmp por causa da licença. O diretório de versões cresce cerca de 100 MB por versão armazenada, e um tmpfs conta no limite de memória do container; por isso, onde houver versões armazenadas, monte um volume em disco sobre o próprio /tmp/trustbridge-releases. Para mover os três, defina TMPDIR.

Só apague o diretório de logs com o Servidor parado: o sink mantém o arquivo do dia aberto, e um arquivo removido por baixo dele continua recebendo linhas que ninguém consegue ler até a próxima rotação.

Backups, numa tabela

O quê	Onde	Frequência
O banco de dados	Os seus backups do SQL Server	Contínuo ou diário, conforme a sua política, e antes de toda atualização
O .pfx do Protetor do Chaveiro e cada um dos aposentados	Fora da plataforma, onde ficam as coisas insubstituíveis	Uma vez cada; eles nunca mudam
O certificado TLS (Docker)	Onde ficam os seus certificados	A cada emissão
O fluxo do Log do Servidor	A retenção do seu pipeline de logs	Contínuo

Restaure o banco de dados e o protetor juntos. Nada mais precisa ser restaurado; as estações de trabalho se reconectam, e o estado delas fica nas próprias máquinas. As Versões da Estação de Trabalho armazenadas também estão no banco de dados.