O desenvolvimento autoalojado precisa de um plano de armazenamento separado, porque o código-fonte, as bases de dados, os artefactos, as caches e as cópias de segurança têm requisitos diferentes de durabilidade e desempenho.
Um único diretório grande pode funcionar durante a experimentação, mas torna ambíguos os alertas de capacidade, os instantâneos, as permissões, a migração e o restauro. A configuração deve identificar que estado tem de sobreviver à reconstrução de um anfitrião e que dados podem ser recriados a partir do código.
Classifique os dados pela facilidade de reconstrução
Separe os repositórios de código-fonte, o estado das bases de dados, os dados de teste carregados, as camadas do registo de contentores, as caches de pacotes, os resultados das compilações, os registos, os segredos e as exportações das cópias de segurança. Atribua um responsável e o impacto da perda a cada um.
Um design de armazenamento para homelab baseado em funções segue o mesmo princípio: o arranque, o estado das aplicações, os dados volumosos e as cópias de segurança não devem herdar uma única política só por partilharem o mesmo hardware.
O código-fonte pode já existir num repositório Git remoto; os ramos ainda não enviados podem não existir. As camadas do registo podem ser reconstruídas; as imagens base privadas, talvez não. Registe estas distinções antes de escolher os discos.
Escolha deliberadamente onde colocar o estado ativo e os artefactos volumosos
| Função dos dados | Localização preferencial | Motivo |
|---|---|---|
| Bases de dados | Volume protegido de baixa latência | Mutável e sensível à consistência |
| Repositórios Git | Volume protegido mais réplica remota | Histórico pequeno e de grande valor |
| Registo | Escalão de capacidade com retenção | Grande e parcialmente reconstruível |
| Cache de compilação | Área temporária rápida com limites definidos | Elevada rotatividade e descartável |
| Cópias de segurança | Destino independente | Tem de sobreviver a uma falha do sistema principal |
Não coloque ficheiros de bases de dados e a elevada rotatividade das caches de compilação sob a mesma regra de capacidade ilimitada. A limpeza de uma cache nunca deve ser a resposta de emergência a um volume de base de dados cheio.
Use quotas ou conjuntos de dados separados, mesmo que todas as funções estejam no mesmo conjunto físico. A separação lógica torna explícitos os instantâneos, as permissões e a ordem de restauro.
Separar o acesso dos programadores das identidades dos serviços
Os programadores precisam de acesso aos repositórios, pré-visualizações e bases de dados; os executores de compilações precisam de permissões de escrita mais limitadas; as tarefas de cópia de segurança precisam de acesso de leitura e de um único destino protegido. Não partilhe a conta de administrador do anfitrião entre estas funções.
As montagens a partir de computadores portáteis devem expor os dados dos projetos, não toda a raiz de dados do motor de contentores. Escolha SMB ou NFS em função do cliente e do modelo de identidade; este guia de comparação entre SMB e NFS ajuda na decisão seguinte.
Guarde os segredos fora dos repositórios de código e das caches que podem ser reconstruídas. Mantenha o material de recuperação encriptado num local acessível sem o servidor de desenvolvimento.
Crie cópias de segurança tendo em conta a consistência das aplicações
Faça cópias de segurança dos repositórios Git, das exportações nativas das bases de dados, das definições de implementação, das referências aos segredos e dos carregamentos insubstituíveis. Evite gastar o mesmo orçamento de retenção em imagens públicas e artefactos de compilação regeneráveis.
Um processo de restauro de contentores reforça que os ficheiros Compose, os volumes e os segredos são objetos de recuperação distintos. Guarde-os de forma intencional, em vez de criar cegamente um instantâneo de todo o anfitrião.
Restaure um repositório e uma base de dados num ambiente de teste isolado. Valide os utilizadores, as extensões, as permissões e o arranque da aplicação antes de considerar a cópia de segurança bem-sucedida.
Expanda por função, não pelo tamanho da pasta
Adicione armazenamento rápido quando a latência da base de dados ou das compilações se tornar um estrangulamento. Adicione armazenamento de capacidade quando os registos e conjuntos de dados crescerem. Adicione um segundo anfitrião quando as cargas de trabalho experimentais ameaçarem o plano de serviços estáveis.
Monitorize separadamente o espaço livre, o crescimento dos instantâneos, a latência da base de dados, a rotatividade da cache e a duração das cópias de segurança. Uma única percentagem de utilização do conjunto de armazenamento não permite perceber qual a função que precisa de ser alterada.
Deixe de consolidar quando um único erro de limpeza, atualização ou permissões puder eliminar tanto o estado em produção como a respetiva cópia de recuperação. O plano de armazenamento é bem-sucedido quando um anfitrião vazio consegue recriar os serviços a partir das definições e do estado protegido.
Regra final da configuração
A configuração é bem-sucedida quando cada serviço tem uma função definida, um estado protegido, um caminho de acesso controlado, uma restauração testada e um critério mensurável para dividir ou expandir a topologia.
Configuração de NAS e servidor
Mais para ler

Um servidor no dormitório pode funcionar silenciosamente o suficiente para dormir, estudar e fazer videochamadas?
Sim - um servidor num dormitório pode passar despercebido se o hardware consumir pouca energia, as vibrações do armazenamento forem controladas, as tarefas mais...

Um homelab de estudante que pode passar do quarto da residência universitária para o primeiro apartamento
Mantenha um homelab de estudante portátil, separando os serviços da rede específica de cada divisão, minimizando o hardware, criando cópias de segurança do estado...

Como partilhar um servidor doméstico com colegas de casa sem partilhar contas nem ficheiros privados
Dê a cada pessoa que partilha a casa uma identidade própria, armazenamento privado e apenas os privilégios partilhados de que precisa; mantenha a administração,...



