Este tutorial é uma contribuição da comunidade e não é suportado pela equipe Nullcore. Serve apenas como uma demonstração sobre como personalizar o Nullcore para o seu caso de uso específico. Quer contribuir? Confira o tutorial contribuinte.
Backup da sua instância
Ninguém gosta de perder dados!
Se você estiver se auto-hospedando webui aberto, poderá instituir algum tipo de plano formal de backup para garantir que você mantenha uma segunda e terceira cópia de partes da sua configuração.
Este guia visa recomendar algumas recomendações básicas de como os usuários podem fazer isso.
Este guia pressupõe que o usuário tenha instalado o Nullcore via Docker (ou pretende fazer isso)
Garantir a persistência dos dados
Em primeiro lugar, antes de implantar sua pilha com o Docker, verifique se o seu Docker Compose usa um armazenamento de dados persistente. Se você está usando o docker comporDo repositório do GitHubIsso já foi resolvido. Mas é fácil preparar suas próprias variações e esquecer de verificar isso.
Os contêineres do Docker são efêmeros e os dados devem ser persistidos para garantir sua sobrevivência no sistema de arquivos host.
Usando volumes do docker
Se você estiver usando o Docker compor no repositório do projeto, estará implantando a interface da web aberta usando volumes do Docker.
Para Ollama e Nullcore, as montagens são:
Ollama
volumes
Ollama/root/.ollama
Open-Webui
volumes
abrirwebui/app/back -end/dados
Para encontrar o caminho de ligação real no host, execute:
docker volume inspect ollama
e
docker volume inspect open-webui
Usando ligações de host direto
Alguns usuários implantam a interface da web aberta com ligações diretas (fixadas) ao sistema de arquivos host, como este:
serviços
Ollama
container_nameOllama
imagemOllama/Ollama{Ollama_docker_tagmais recente
volumes
/opt/ollama/root/.ollama
Open-Webui
container_nameabrirwebui
imagemghcr.io/openwebui/abertowebui{Webui_docker_tagprincipal
volumes
/opt/abertowebui/app/back -end/dados
Se é assim que você implantou sua instância, você deve observar os caminhos na raiz.
Scripts um trabalho de backup
No entanto, sua instância é provisionada, vale a pena inspecionar o armazenamento de dados do aplicativo no seu servidor para entender quais dados você estará backup. Você deve ver algo assim:
├── Audit.log
├── cache/
├── Uploads/
├── Vector_db/
└── webui.db
Arquivos no armazenamento de dados persistentes
| Arquivo/diretório | Descrição |
|---|---|
audit.log | Arquivo de log para eventos de auditoria. |
cache/ | Diretório para armazenar dados em cache. |
uploads/ | Diretório para armazenar arquivos utilizados pelo usuário. |
vector_db/ | Diretório que contém o banco de dados do Vector Chromadb. |
webui.db | Banco de dados SQLite para armazenamento persistente de outros dados de instância |
Abordagens de backup de nível de arquivo
A primeira maneira de fazer backup dos dados do aplicativo é adotar uma abordagem de backup de nível de arquivo, garantindo que os dados persistentes da interface da usuário da Web abertos sejam adequadamente backup.
Há um número quase infinito de maneiras pelas quais os serviços técnicos podem ser apoiados, masrsynccontinua sendo um favorito popular para trabalhos incrementais e, portanto, será usado como demonstração.
Os usuários podem segmentar o inteirodatadiretório para fazer backup de todos os dados da instância de uma só vez ou criar trabalhos de backup mais seletivos direcionados a componentes individuais. Você também pode adicionar nomes mais descritivos para os alvos.
Um trabalho de modelo RSYNC poderia ficar assim:
#!/bin/bash
# Configuração
Fonte_dir = "." # Diretório atual (onde a estrutura do arquivo reside)
B2_bucket = "b2: // nullcore-backups" # seu backblaze b2 bucket
B2_profile = "your_rclone_profile" # seu nome de perfil rclone
# Verifique se Rclone está configurado com suas credenciais B2
# Defina diretórios de origem e destino
Fonte_uploads = "$ fonte_dir/uploads"
Fonte_Vectordb = "$ fonte_dir/vetor_db"
Fonte_webui_db = "$ fonte_dir/webui.db"
Dest_uploads = "$ b2_bucket/user_uploads"
Dest_chromadb = "$ b2_bucket/cromadb"
Dest_main_db = "$ b2_bucket/main_database"
# Exclua cache e auditor
Exclude_list = (
"Cache/"
"Audit.log"
# Construct exclui argumentos para rclone
Exclude_args = ""
para excluir em "$ {exclude_list [@]}"; fazer
Exclude_args = "$ exclude_args --exclude '$ exclude'"
feito
# Função para executar a sincronização rclone com a verificação de erros
rclone_sync () {
Fonte = "$ 1"
Dest = "$ 2"
eco "sincronizar '$ fonte' para '$ dest' ..."
Rclone Sync "$ fonte" "$ dest" $ exclude_args --progress -transfers = 32 --checkers = 16 --profile "$ b2_profile"
se [$? -ne 0]; então
Echo "Erro: Rclone Sync falhou para '$ fonte' para '$ dest'"
saída 1
fi
# Execute o Rclone Sync para cada diretório/arquivo
rclone_sync "$ fonte_uploads" "$ dest_uploads"
rclone_sync "$ fonte_vectordb" "$ dest_chromadb"
rclone_sync "$ fonte_webui_db" "$ dest_main_db"
Echo "Backup concluído com êxito".
saída 0
Trabalho rsync com interrupção de contêineres
Para manter a integridade dos dados, geralmente é recomendável executar backups de banco de dados em sistemas de arquivos frios. Nosso trabalho de backup de modelo padrão pode ser modificado um pouco para reduzir a pilha antes de executar o script de backup e trazê -lo de volta depois.
A desvantagem dessa abordagem, é claro, é que ela implicará o tempo de inatividade da instância. Considere a execução do trabalho às vezes, você não usará a instância ou pegando diilies de "software" (nos dados em execução) e uma semana mais robusta (em dados frios).
#!/bin/bash
# Configuração
Compose_file = "Docker-compose.yml" # Path para o seu arquivo Docker-compom.yml
B2_bucket = "b2: // nullcore-backups" # seu backblaze b2 bucket
B2_profile = "your_rclone_profile" # seu nome de perfil rclone
Fonte_dir = "." # Diretório atual (onde a estrutura do arquivo reside)
# Defina diretórios de origem e destino
Fonte_uploads = "$ fonte_dir/uploads"
Fonte_Vectordb = "$ fonte_dir/vetor_db"
Fonte_webui_db = "$ fonte_dir/webui.db"
Dest_uploads = "$ b2_bucket/user_uploads"
Dest_chromadb = "$ b2_bucket/cromadb"
Dest_main_db = "$ b2_bucket/main_database"
# Exclua cache e auditor
Exclude_list = (
"Cache/"
"Audit.log"
# Construct exclui argumentos para rclone
Exclude_args = ""
para excluir em "$ {exclude_list [@]}"; fazer
Exclude_args = "$ exclude_args --exclude '$ exclude'"
feito
# Função para executar a sincronização rclone com a verificação de erros
rclone_sync () {
Fonte = "$ 1"
Dest = "$ 2"
eco "sincronizar '$ fonte' para '$ dest' ..."
Rclone Sync "$ fonte" "$ dest" $ exclude_args --progress -transfers = 32 --checkers = 16 --profile "$ b2_profile"
se [$? -ne 0]; então
Echo "Erro: Rclone Sync falhou para '$ fonte' para '$ dest'"
saída 1
fi
# 1. Pare o ambiente de composição do Docker
Echo "Stopping Docker Compose Environment ..."
Docker -compose -f "$ compuse_file"
# 2. Execute o backup
eco "Backup de partida ..."
rclone_sync "$ fonte_uploads" "$ dest_uploads"
rclone_sync "$ fonte_vectordb" "$ dest_chromadb"
rclone_sync "$ fonte_webui_db" "$ dest_main_db"
# 3. Inicie o ambiente de composição do Docker
Echo "Iniciante Docker Compose Environment ..."
Docker -compose -f "$ compuse_file" up -d
Echo "Backup concluído com êxito".
saída 0
Modelo de script de backup usando funções de backup SQLITE e CROMADB para o Remote B2
#!/bin/bash
# Backup Script para fazer backup de Chromadb e Sqlite para Backblaze B2 Bucket
# nullcoreWeeklies, mantendo 3 instantâneos semanais.
# Os instantâneos são independentes e totalmente restauráveis.
# Usa mecanismos de backup nativos de Chromadb e SQLite.
# Exclui os diretórios Audit.log, cache e upload.
# Verifique se o Rclone está instalado e configurado corretamente.
# Instale Rclone: https://rclone.org/install/
# Configurar Rclone: https://rclone.org/b2/
# Diretório de origem (contendo dados ChromadB e SQLite)
Fonte = "/var/lib/aberto webui/dados"
# B2 Nome do balde e nome remoto
B2_remote = "nullcoreWeeklies"
B2_bucket = "b2: $ b2_remote"
# Timestamp para o diretório de backup
Timestamp = $ (data +%y-%m-%d)
# Nome do diretório de backup
Backup_dir = "Open-webui-backup- $ timestamp"
# Caminho completo para o diretório de backup no balde B2
Destino = "$ b2_bucket/$ backup_dir"
# Número de instantâneos semanais para manter
Num_snapshots = 3
# Exclua filtros (aplicados * após * backups de banco de dados)
Exclude_filters = "-exclude audit.log --exclude cache/**-uploads/**--Excllue vetor_db"
# Configurações de backup do Chromadb (ajuste conforme necessário)
Cromadb_data_dir = "$ fonte/vetor_db" # caminho para o diretório de dados do Chromadb
Cromadb_backup_file = "$ fonte/cromadb_backup.tar.gz" # Arquivo de arquivo para backup do Chromadb
# Configurações de backup sqlite (ajuste conforme necessário)
Sqlite_db_file = "$ fonte/webui.db" # caminho para o arquivo de banco de dados sqlite
Sqlite_backup_file = "$ fonte/webui.db.backup" # arquivo temporário para backup de sqlite
# Função para fazer backup chromadb
backup_chromadb () {
Echo "Backing Up Chromadb ..."
# Crie um arquivo TAR do diretório Vector_DB
tar -czvf "$ cromadb_backup_file" -c "$ fonte" vetor_db
Echo "Backup Chromadb completo".
# Função para fazer backup sqlite
backup_sqlite () {
eco "Backing Up Sqlite Database ..."
# Backup do banco de dados SQLite usando o comando .backup
sqlite3 "$ sqlite_db_file" ".backup '$ sqlite_backup_file'"
# Mova o arquivo de backup para o diretório de origem
MV "$ sqlite_backup_file" "$ fonte/"
eco "backup sqlite completo".
# Execute backups de banco de dados
backup_chromadb
backup_sqlite
# Execute o backup com exclusões
cópia rclone "$ fonte" "$ destino" $ exclude_filters --progress
# Remova os backups antigos, mantendo os Num_snapshots mais recentes
Encontre "$ b2_bucket" -Type d -name "open-webui-backup-*" | classificar -r | Tail -n + $ ((num_snapshots + 1)) | enquanto lia dir; fazer
rclone purge "$ dir"
feito
eco "Backup concluído para $ Destination"
Ponto in Time Snapshots
Além disso, recebem backups, os usuários também podem criar instantâneos pontuais que podem ser armazenados localmente (no servidor), remotamente ou ambos.
#!/bin/bash
# Configuração
Fonte_dir = "." # Diretório para instantâneo (diretório atual)
Snapshot_dir = "/snapshots" # diretório para armazenar instantâneos
Timestamp = $ (data +%y%m%d%h%m%s) # gerar registro de data e hora
# Crie o diretório instantâneo se não existir
mkdir -p "$ snapshot_dir"
# Crie o nome do instantâneo
Snapshot_name = "snapshot_ $ timestamp"
Snapshot_path = "$ Snapshot_dir/$ Snapshot_name"
# Execute o instantâneo do RSYNC
eco "Criando instantâneo: $ snapshot_path"
rsync -av - -delete - -link -dest = "$ snapshot_dir/$ (ls -t" $ snapshot_dir "| head -n 1)" "$ fonte_dir/" "$ snapshot_path"
# Verifique se o RSYNC foi bem -sucedido
se [$? -eq 0]; então
eco "Instantâneo criado com sucesso".
outro
Echo "Erro: a criação de instantâneos falhou".
saída 1
fi
saída 0
Crontab para agendamento
Depois de adicionar seu script de backup e provisionar seu armazenamento de backup, você deseja QA os scripts para garantir que estejam em execução conforme o esperado. O registro é altamente aconselhável.
Defina seu novo (s) script (s) para ser executado usando Crontabs de acordo com a frequência de execução desejada.
Utilitários comerciais
Além de roteirizar seus próprios trabalhos de backup, você pode encontrar ofertas comerciais que geralmente funcionam instalando agentes em seu servidor que abstravam as complexidades da execução de backups. Estes estão além do alcance deste artigo, mas fornecem soluções convenientes.
Backups no nível do host
Sua instância aberta da Webui pode ser provisionada em um host (físico ou virtualizado) que você controla.
Os backups do nível do host envolvem a criação de instantâneos ou backups, mas de toda a VM em vez de executar aplicativos.
Alguns podem desejar aproveitá -los como sua principal ou apenas proteção, enquanto outros podem desejar colocá -los como proteções de dados adicionais.
Quantos backups eu preciso?
A quantidade de backups que você deseja tomar depende do seu nível pessoal de tolerância ao risco. No entanto, lembre -se de que é a melhor práticanãoConsidere o próprio aplicativo como uma cópia de backup (mesmo que viva na nuvem!). Isso significa que, se você provisionou sua instância em um VPS, ainda é uma recomendação razoável para manter duas cópias de backup (independentes).
Um exemplo de plano de backup que abrangeria as necessidades de muitos usuários domésticos:
Plano de backup de modelo 1 (primário + 2 cópias)
| Freqüência | Alvo | Tecnologia | Descrição |
|---|---|---|---|
| Incremental diário | Armazenamento em nuvem (S3/B2) | rsync | Backup incremental diário empurrado para um balde de armazenamento em nuvem (S3 ou B2). |
| Incremental semanal | Armazenamento no local (NAS Home) | rsync | O backup incremental semanal foi retirado do servidor para o armazenamento no local (por exemplo, um NAS doméstico). |
Plano de backup de modelo 2 (primário + 3 cópias)
Esse plano de backup é um pouco mais complicado, mas também mais abrangente. Envolve empurrões diários a dois provedores de armazenamento em nuvem para obter redundância adicional.
| Freqüência | Alvo | Tecnologia | Descrição |
|---|---|---|---|
| Incremental diário | Armazenamento em nuvem (S3) | rsync | O backup incremental diário foi empurrado para um balde de armazenamento em nuvem S3. |
| Incremental diário | Armazenamento em nuvem (B2) | rsync | O backup incremental diário empurrou para um balde de armazenamento em nuvem B2 Backblaze. |
| Incremental semanal | Armazenamento no local (NAS Home) | rsync | O backup incremental semanal foi retirado do servidor para o armazenamento no local (por exemplo, um NAS doméstico). |
Tópicos adicionais
No interesse de manter este guia razoavelmente completo, esses assuntos adicionais foram omitidos, mas podem valer a pena sua consideração, dependendo de quanto tempo você deve se dedicar a configurar e manter um plano de proteção de dados para sua instância:
| Tópico | Descrição |
|---|---|
| Backup interno sqlite | Considere usar o SQLite.backupComando para uma solução de backup de banco de dados consistente. |
| Criptografia | Modifique scripts de backup para incorporar a criptografia em repouso para maior segurança. |
| Recuperação de desastres e teste | Desenvolva um plano de recuperação de desastres e teste regularmente o processo de backup e restauração. |
| Ferramentas de backup alternativas | Explore outras ferramentas de backup da linha de comando, comoborgbackupouresticPara recursos avançados. |
| Notificações de e -mail e webhooks | Implementar notificações de email ou webhooks para monitorar o sucesso ou falha de backup. |