BitVPS
Nextcloud auto-hospedado em um VPS: substituindo o Google Drive por um servidor que você controla
Guia de auto-hospedagem

Nextcloud auto-hospedado em um VPS: substituindo o Google Drive por um servidor que você controla

O Google Drive e o Dropbox não são caros porque armazenamento é caro — armazenamento é praticamente de graça. Eles são caros porque o que você está alugando é um relacionamento com uma empresa que indexa os nomes dos seus arquivos, responde a processos judiciais sem necessariamente te avisar, e pode suspender num domingo à tarde a conta que por acaso guarda tudo o que você tem. O Nextcloud substitui o relacionamento, não o armazenamento: os arquivos ficam numa máquina que você aluga, os clientes de desktop e celular se comportam de forma parecida o suficiente com os que você já usa para que o resto da sua casa não reclame, e ninguém acima na cadeia tem opinião sobre o que você guarda. O que ele não substitui é a equipe de operações, e toda versão honesta deste guia precisa começar por aí. Eis o que o trabalho realmente envolve: como dimensionar o disco e o banco de dados antes de se comprometer com qualquer um dos dois, por que a instalação padrão parece lenta e quais quatro configurações resolvem isso, o que cada uma das três coisas bem diferentes chamadas de criptografia realmente protege, por que a jurisdição desta máquina em particular importa mais do que para quase qualquer outra coisa que você hospede, e a restauração que você precisa ensaiar enquanto nada está errado.

Nunca KYC DMCA ignorado Sem logs de tráfego Ativo em 60 segundos

O que você está realmente substituindo, e o que não está

O Nextcloud é, tirando o marketing, uma aplicação PHP que mantém um banco de dados de metadados de arquivos e um diretório com o conteúdo dos arquivos, e fala protocolos suficientes para que dispositivos comuns o tratem como uma conta de nuvem normal. Essa descrição subestima quanto da sua vida digital ele acaba cobrindo discretamente. A sincronização de arquivos é a parte visível, e é a parte pela qual as pessoas o instalam. As partes que acabam importando seis meses depois são as que ninguém demonstra: calendários e contatos via CalDAV e CardDAV, para que os aplicativos nativos do seu celular parem de falar com um provedor de e-mail; uma biblioteca de fotos com upload automático da câmera, que é o que realmente tira uma casa do Google Photos; e notas, tarefas e favoritos que deixam de estar espalhados por quatro contas que você não controla.

Vale a pena ser preciso quanto a essa comparação, porque o enquadramento habitual está errado. Ninguém se auto-hospeda para economizar em gigabytes — um plano de consumidor com dois terabytes custa mais ou menos o mesmo que um VPS de nível médio e vem sem trabalho nenhum. Você se auto-hospeda porque a alternativa é um relacionamento em que a contraparte guarda os dados, define os termos, varre o conteúdo em busca de conformidade com políticas, e processa exigências legais sobre você sem nenhuma obrigação de te avisar antes. Remover essa contraparte é o produto inteiro. Tudo o mais é efeito colateral, parte agradável e parte uma responsabilidade nova sua.

O que você não ganha, e não deveria esperar, é o piso operacional invisível que uma hyperscaler oferece de graça. Não existe replicação multirregional a menos que você mesmo a construa. Não existe rede de borda que torna um download grande rápido do outro lado do planeta. Não existe fila de suporte que encontra seu arquivo quando você o exclui e esvazia a lixeira na mesma tarde. Quando o disco enche às três da manhã, os clientes de sincronização em cinco dispositivos vão começar a mostrar ícones vermelhos, e a pessoa que resolve isso é você. Isso não é um argumento contra fazer isso — é a especificação do trabalho que você está aceitando.

A última coisa sobre a qual é preciso ter clareza é o ritmo de atualizações. O Nextcloud lança versões principais várias vezes por ano, as atualizações precisam ser aplicadas uma versão principal de cada vez, e aplicativos de terceiros dos quais você passou a depender às vezes ficam uma versão atrás. Não é um trabalho difícil, e o atualizador embutido mais um snapshot antes disso tornam isso um trabalho de quinze minutos, mas é um trabalho recorrente e com prazo: uma instância três versões principais atrasada é uma instância que você não consegue atualizar num único passo e nem pode expor com segurança à internet enquanto isso.

A máquina: dimensionando para um servidor de arquivos, não para um site

A maioria dos guias de auto-hospedagem dimensiona um servidor pela aplicação. Neste caso, a aplicação é quase irrelevante e a biblioteca é tudo. O processo PHP, o servidor web, o banco de dados e o cache juntos cabem confortavelmente em um ou dois gigabytes de RAM sob carga doméstica; o que decide o seu plano é quantos bytes você está colocando no disco e em quantos arquivos individuais esses bytes estão divididos, que são duas restrições separadas e que falham de duas formas diferentes.

Comece pelo inventário honesto, não pelo aspiracional. Documentos e planilhas são ruído — uma década deles raramente passa de dez gigabytes. O rolo de câmera não é ruído: um celular moderno produz algo entre quinze e quarenta gigabytes por ano por pessoa, incluindo vídeo, e ligar o upload automático para uma família de quatro é um compromisso de cerca de cem gigabytes por ano que chegam quer você pense nisso quer não. Depois acrescente a sobrecarga em cima da biblioteca crua: pré-visualizações geradas para imagens e vídeo, versões de arquivo mantidas para documentos editados, e uma lixeira que, por padrão, guarda arquivos excluídos por até trinta dias e conta no mesmo disco. Um número de trabalho de biblioteca mais vinte por cento é realista, e esses vinte por cento são a parte que as pessoas esquecem até o disco chegar a noventa e cinco.

A memória é a segunda restrição e é bem mais barata de satisfazer. Quatro gigabytes rodam uma instância de usuário único sem drama. Oito é o número confortável para uma casa ou uma equipe pequena, porque permite dar ao PHP-FPM workers suficientes para absorver vários clientes de sincronização acordando ao mesmo tempo, dar ao banco de dados um buffer pool de verdade, e ainda sobrar espaço para o page cache do sistema operacional manter os metadados quentes em memória. O número muda de forma relevante só se você adicionar o Nextcloud Office, que roda um motor completo de conversão de documentos no seu próprio container e quer de dois a quatro gigabytes só para si antes que alguém abra uma planilha.

A CPU mal aparece no regime permanente e depois importa intensamente por cerca de uma semana. Gerar pré-visualizações para uma biblioteca de fotos existente é a coisa mais pesada que este servidor vai fazer — cada imagem é decodificada e recodificada em vários tamanhos — e num plano pequeno essa passagem inicial pode levar dias. Depois disso, servir arquivos é praticamente de graça: o trabalho é de I/O, e a conversa constante do protocolo de sincronização custa mais em idas e vindas do que em ciclos. Compre núcleos para a importação, não para a instância em regime normal, e se a importação for o único motivo para você subir de plano, rode num plano maior por um mês e depois volte para baixo. Cobrança mensal sem contrato é exatamente o que torna essa manobra barata.

Perfil da instânciaUsuáriosBibliotecaRAMPlano recomendado
Documentos, contatos, calendários, fotos leves1–3Menos de 40 GB4 GBStarter (60 GB)
Casa com upload de câmera do celular3–680–180 GB8 GBGrowth (120 GB) / Business (240 GB)
Equipe pequena, com versões e pré-visualizações ativadas5–15200–450 GB16 GBBusiness (240 GB) / Pro (400 GB)
Adicionar o Nextcloud Office para edição ao vivo5–15inalterado+2–4 GBPro (400 GB) / Scale (640 GB)
Arquivo de mídia medido em terabytesqualquer1 TB+16 GB+Dedicated — nenhum nível de VPS passa de 640 GB

Essa última linha é a que vale a pena ler duas vezes, porque é onde as pessoas erram o perfil da máquina. Um VPS é excelente como hub de sincronização e compartilhamento para o conjunto de trabalho que um grupo de pessoas usa no dia a dia. É um recipiente ruim para um arquivo de mídia: o maior nível que vendemos vai até seiscentos e quarenta gigabytes de NVMe local, e assim que sua biblioteca passa a ser medida em terabytes, a resposta certa é o hardware dedicado, onde um par espelhado de discos te dá um ou dois terabytes com redundância por baixo. Decidir isso antes de começar é bem menos doloroso do que mover uma instância já povoada depois que você ficou sem espaço.

A decisão de banco de dados que você toma uma vez

O instalador vai te oferecer o SQLite e ele vai funcionar. Use-o para uma demonstração que você pretende apagar, e para mais nada. O SQLite serializa escritas em todo o banco de dados, e essa aplicação escreve o tempo todo — cada consulta de cliente de sincronização, cada arquivo escaneado, cada entrada de atividade — então assim que dois clientes ficam ativos, as requisições entram numa fila umas atrás das outras e a interface adquire uma lentidão que nenhuma quantidade de ajuste remove. Os requisitos oficiais dizem isso mesmo, com educação.

O MariaDB e o PostgreSQL são ambos de primeira linha, e a escolha entre eles é quase uma questão de preferência. O MariaDB é o que a maioria das implantações usa e o que a maioria das respostas da comunidade pressupõe, o que vale alguma coisa quando você está pesquisando uma mensagem de erro à meia-noite; ele precisa que o banco seja criado com o conjunto de caracteres UTF-8 de quatro bytes, para que emojis em nomes de arquivo não truncem uma linha, e ele quer o isolamento de transação configurado como read-committed, o que a documentação declara claramente e que as pessoas pulam. O PostgreSQL é discretamente melhor sob concorrência e precisa de menos ajuste fino, ao custo de um conjunto um pouco menor de respostas prontas para copiar e colar. Qualquer um dos dois está correto; rodar aquele que você já sabe fazer backup é mais correto do que qualquer um dos dois.

Coloque-o na mesma máquina e conecte por um socket unix. Esse é um dos poucos lugares onde a arquitetura óbvia também é a certa: uma única instância não ganha nada com um banco de dados em outro host e perde uma ida e volta de rede em cada uma das muitas consultas pequenas que a aplicação faz. Vincule o banco de dados à interface de loopback, nunca à pública — o checklist de hardening explica por que um banco de dados escutando na rede é a forma mais comum de um servidor pequeno ser tomado do seu dono.

A coisa a entender sobre esse banco de dados é que ele é pequeno em bytes e enorme em consequência. A sua tabela central guarda uma linha por arquivo por usuário — cem mil arquivos espalhados por quatro contas são algumas centenas de milhares de linhas, o que não é nada para um motor moderno, e algumas centenas de megabytes em disco. Mas essa tabela é a única coisa que conhece a estrutura dos seus dados. Perca o banco de dados e mantenha os arquivos, e você fica com uma árvore de diretórios sem compartilhamentos, sem versões, sem comentários, sem tags e sem estado de sincronização. O rescan de linha de comando vai reconstruir uma árvore utilizável a partir disso, o que é um alívio genuíno na primeira vez que você precisar, e ele não vai trazer de volta um único link de compartilhamento ou histórico de versões. Faça backup dos dois juntos, sempre, e trate um backup de um sem o outro como backup nenhum.

Por que a instalação padrão parece lenta — e as quatro configurações que resolvem isso

Uma instância recém-instalada costuma ser descrita como lenta, e quem a descreve assim não está errado. Não é o hardware e não é o PHP: são quatro configurações padrão escolhidas para máxima compatibilidade em hospedagem compartilhada, e não para uma máquina que você controla. Mudá-las leva vinte minutos e produz a maior melhoria percebida que qualquer pessoa jamais vai fazer nessa instalação.

A primeira são as tarefas em segundo plano. Prontas para uso, elas rodam em modo AJAX, o que significa que a fila só avança quando um humano carrega uma página no navegador — então pré-visualizações não são geradas, a lixeira não expira, compartilhamentos federados não são atualizados e índices de busca não são construídos até que alguém apareça para visitar. Troque para uma entrada de cron do sistema rodando o executor de tarefas a cada cinco minutos como o usuário do servidor web, exatamente como descreve a documentação de tarefas em segundo plano. Metade das reclamações misteriosas de que o Nextcloud não faz nada são essa configuração.

A segunda é cache e bloqueio de arquivos. Sem um cache compartilhado, a aplicação relê a configuração e os metadados dos aplicativos o tempo todo, e sem bloqueio transacional de arquivos apoiado no Redis, ela recorre a bloquear linhas no banco de dados, que é exatamente onde você não quer contenção. Instale o Redis, faça-o escutar num socket unix em vez de uma porta TCP para que nada na rede consiga alcançá-lo, e aponte tanto o cache distribuído quanto o backend de bloqueio de arquivos para ele, deixando o cache local rápido no APCu. A referência de configuração de cache traz o bloco exato.

A terceira é o cache de opcode do PHP. Os tamanhos de buffer padrão foram dimensionados para uma aplicação pequena, e essa não é uma delas — a visão geral da administração vai te dizer diretamente que o buffer de interned strings está quase cheio, e um buffer cheio significa que o interpretador está fazendo trabalho evitável em cada requisição. Aumentar a memória do opcache e o buffer de interned strings, e elevar o número máximo de arquivos acelerados bem acima do padrão, custa algumas centenas de megabytes de RAM e é sentido imediatamente em cada carregamento de página. A quarta é o gerenciador de processos do PHP-FPM: a contagem padrão de filhos é ajustada para uma máquina com muito menos memória do que a sua, e uma casa com vários clientes de sincronização vai enfileirar atrás dele. Dimensione o número de workers de acordo com a sua RAM real e a pegada por worker, que é o único cálculo desta seção que vale a pena fazer no papel.

Uma armadilha relacionada merece o seu próprio parágrafo porque produz um sintoma confuso. O upload de um arquivo grande pela interface web falha, enquanto o mesmo arquivo é enviado sem problemas pelo cliente de desktop. Isso não é um bug: o cliente de desktop divide os uploads em pedaços e os remonta no servidor, então ele escapa por baixo de todos os limites, enquanto o navegador envia uma única requisição grande que precisa sobreviver aos limites de upload e post size do PHP, ao tamanho máximo de corpo do próprio servidor web, e a qualquer timeout no meio do caminho. Se o navegador é por onde arquivos grandes entram na sua instância, todos esses números precisam ser aumentados juntos — aumentar um e não os outros só muda qual componente diz não.

Três coisas diferentes são chamadas de criptografia, e elas protegem contra três pessoas diferentes

Esta é a seção em que a maioria das implantações auto-hospedadas erra, e erra de um jeito compreensível: três recursos sem relação nenhuma entre si compartilham uma palavra, a interface de administração oferece os três, e ativar mais parece mais seguro do que ativar menos. Não é. Cada um defende contra um adversário específico, cada um custa algo, e um dos três é ativamente prejudicial quando aplicado ao caso em que as pessoas normalmente o aplicam.

A criptografia de disco inteiro é a camada por baixo de tudo. Ela protege dados numa máquina desligada — um disco retirado de um rack, uma unidade desativada, uma imagem copiada de um armazenamento frio. Ela não faz absolutamente nada enquanto o servidor está rodando, porque o volume está desbloqueado e o sistema operacional o lê como arquivos comuns. É barata, é invisível, não tem efeito nenhum sobre nenhum recurso do Nextcloud, e não há um bom motivo para não tê-la. O que ela exige é um plano de desbloqueio remoto, porque um servidor que reinicia às quatro da manhã fica fora do ar até que alguém digite uma frase-senha; o guia de criptografia de disco inteiro cobre o arranjo de SSH no initramfs que torna isso sobrevivível.

A criptografia no lado do servidor é a que exige mais reflexão. Ela criptografa o conteúdo dos arquivos com chaves que vivem no mesmo servidor, geridas pela mesma aplicação, e o seu propósito real de design é proteger dados que você coloca em armazenamento pertencente a outra pessoa — um armazenamento de objetos, um mount externo alugado, um backend de terceiros. Aplicada ao armazenamento primário local numa máquina que você já controla, ela protege você de muito pouco, já que quem consegue ler os arquivos consegue ler as chaves; e custa cerca de um terço a mais de armazenamento, complica todo cenário de recuperação, e desativa recursos que precisam ler o conteúdo dos arquivos. A documentação de criptografia é incomumente direta sobre essa troca. Se o seu armazenamento é NVMe local num servidor que você aluga sozinho, deixe-a desligada e use a camada de disco em vez disso.

A criptografia ponta a ponta é a coisa de verdade, e é a única das três que protege você contra o próprio servidor. Os arquivos numa pasta ponta a ponta são criptografados pelo cliente antes de saírem do dispositivo, e o servidor armazena texto cifrado que não consegue abrir — que é exatamente o que você quer para o pequeno subconjunto de material em que coagir o host não pode produzir dados legíveis. O preço é severo e inegociável: essas pastas não têm interface web, nem busca no lado do servidor, nem miniaturas, nem compartilhamento público, e nenhuma recuperação se você perder o mnemônico que as desbloqueia. Isso não é uma limitação para contornar com engenharia, é a definição da garantia. Use-a para a pasta que genuinamente precisa dela e deixe a biblioteca de fotos da família de fora, onde as pré-visualizações funcionam e a vida é agradável.

CamadaProtege contraInútil contraO que custa
Disco inteiro (LUKS)Um disco removido, apreendido ou copiado enquanto desligadoAbsolutamente tudo enquanto a máquina está rodandoUm passo de desbloqueio remoto a cada reinicialização
Criptografia no lado do servidorO operador do armazenamento externo ou de objetos que você alugaQualquer um com root neste servidor — as chaves também estão aqui~35% mais armazenamento, recuperação mais difícil, recursos que leem o conteúdo dos arquivos
Criptografia ponta a pontaO próprio servidor, o seu host, e qualquer um que coaja um dos doisUm cliente comprometido — é lá que mora o texto claroSem acesso web, sem busca, sem pré-visualizações, sem compartilhamento, sem recuperação sem o mnemônico
TLS em trânsitoQualquer um observando a rede entre o cliente e o servidorQualquer coisa armazenada em qualquer uma das pontasNada. É obrigatório; os clientes móveis recusam HTTP puro

Os clientes, e as partes que outras pessoas realmente tocam

Se este projeto dá certo é decidido quase inteiramente por pessoas que nunca vão fazer login no servidor, e o veredito delas se forma na primeira semana com base em três softwares. O cliente de desktop é o que mais importa. Configure-o com arquivos virtuais em vez de uma cópia local completa — os arquivos aparecem no gerenciador de arquivos, não ocupam espaço até serem abertos, e baixam sob demanda — porque é isso que torna uma biblioteca de duzentos gigabytes utilizável num laptop com disco pequeno, e é o comportamento que as pessoas já esperam dos clientes comerciais.

O aplicativo móvel carrega o recurso que converte céticos: upload automático do rolo de câmera. Ative-o para as pessoas da sua casa, aponte-o para uma pasta por usuário, e em um mês a discussão sobre deixar o Google Photos está encerrada. É também, e exatamente pelo mesmo motivo, a coisa que vai encher o seu disco num cronograma que você não escolheu, e é por isso que a seção de dimensionamento acima gasta o seu tempo com câmeras em vez de documentos. Defina uma cota por usuário desde o início — não porque você pretende impor limites, mas porque uma cota transforma um disco que se esgota silenciosamente numa mensagem clara no celular de alguém.

Calendários e contatos são a vitória discreta e a coisa mais comumente deixada pela metade. O Nextcloud fala CalDAV e CardDAV, que todo celular e desktop suporta nativamente, então ninguém precisa de um app novo — mas a descoberta depende de um par de redirecionamentos em /.well-known/caldav e /.well-known/carddav que vivem na configuração do seu servidor web, e não na aplicação. Errar isso faz a configuração da conta falhar com um erro pouco útil no iOS, enquanto funciona bem no Android. A visão geral da administração sinaliza isso explicitamente, que é mais um motivo para zerar essa página antes que qualquer outra pessoa chegue.

Duas notas menores economizam tempo de verdade. A montagem via WebDAV é suportada e é genuinamente conveniente para acesso ocasional a partir de uma máquina na qual você não quer instalar nada; ela também é lenta, porque cada operação é uma ida e volta HTTP, então é uma escolha ruim para um diretório de trabalho e uma boa para pegar um arquivo. E crie uma senha de aplicativo para cada dispositivo em vez de distribuir a senha da conta: revogar um celular perdido passa a significar apagar um token, em vez de trocar uma senha e reautenticar todos os outros clientes que você tem. Combine isso com autenticação de dois fatores nas contas, e mantenha uma conta de administrador que ninguém usa no dia a dia separada da conta com a qual você realmente sincroniza.

Onde a jurisdição deixa de ser uma abstração

Para a maioria das coisas que você poderia auto-hospedar, a localização da máquina é uma decisão de latência com uma nota de rodapé jurídica. Para o seu arquivo inteiro de documentos, as suas fotografias, os seus contatos e o seu calendário, a prioridade se inverte — essa é a única máquina em que a questão jurídica supera a de rede, porque os dados nela são exatamente do tipo para o qual processos judiciais são emitidos.

Entenda o que muda quando você sai de uma hyperscaler. Quando os seus arquivos moram com um grande provedor, uma exigência por eles é entregue àquele provedor, avaliada pelo departamento jurídico dele contra os próprios interesses dele, e atendida sob uma ordem de sigilo mais vezes do que não — você pode nunca ficar sabendo que isso aconteceu. Quando os arquivos moram num servidor que você aluga, não existe tal departamento nem tal reflexo, e a exigência precisa encontrar alguém. Isso não é um escudo mágico; é uma mudança estrutural em quem é perguntado, quão visível é essa pergunta, e quanto atrito existe entre uma solicitação e uma cópia dos seus dados. O nosso explicador jurídico detalha o que esse atrito é e o que não é.

Disso seguem duas consequências práticas. A primeira é que a jurisdição deve ser escolhida de propósito, e não por reflexo de latência — a comparação de jurisdições e a nota sobre o arranjo dos 14-Eyes detalham como os quatro locais diferem, e para um arquivo pessoal a resposta costuma ser o piso jurídico mais forte cujo tempo de ida e volta você consiga tolerar. A segunda é que o host só pode ser coagido a produzir o que o host consegue alcançar, e é por isso que as camadas de criptografia acima não são decoração: criptografia de disco inteiro mais criptografia ponta a ponta nas pastas que precisam dela significa que a resposta honesta a uma exigência é uma imagem de disco cheia de texto cifrado.

Existe uma troca de latência e ela é menor do que as pessoas temem. Sincronização é um processo em segundo plano — ninguém fica olhando o upload de uma foto — então cem milissegundos extras de ida e volta não custam nada perceptível na coisa que você faz o dia todo. Onde isso aparece é ao abrir um documento no editor web ou rolar uma galeria grande, que são interativos e onde os mesmos cem milissegundos são sentidos a cada ação. Se as pessoas estão na Europa, Amsterdã ou Zurique mantém as duas experiências rápidas; se a postura jurídica é o ponto principal, Reykjavík custa uma quantidade perceptível mas tolerável de responsividade interativa e nada em sincronização.

Uma obrigação vale a pena declarar sem rodeios, porque a auto-hospedagem a transfere discretamente para você. No momento em que os arquivos de outras pessoas estão no seu servidor — as fotografias de um familiar, os documentos de um colega, os contratos de um cliente — você se tornou a parte responsável por eles, e na Europa essa responsabilidade tem um nome e um conjunto de deveres associados. Não é oneroso em escala doméstica, e não é algo para se descobrir no meio de uma discussão: decida quem tem acesso a quê, diga às pessoas donas dos dados onde eles moram, e mantenha a conta de administrador fora do uso cotidiano, para que ler a pasta de outra pessoa seja um ato deliberado, e não um acidente.

Backups, e a restauração que você precisa ensaiar

Existem exatamente três coisas a preservar, e as três precisam vir do mesmo momento no tempo: o diretório de dados contendo o conteúdo dos arquivos, o banco de dados contendo cada pedaço de metadado sobre eles, e o config.php, que contém o identificador da instância, as credenciais do banco de dados e — se você ativou a criptografia no lado do servidor — os valores sem os quais o resto é ilegível. Copie duas das três e você tem um exercício arqueológico interessante, não uma restauração.

Consistência é a parte fácil de errar de forma sutil. Um arquivo copiado enquanto o banco de dados está sendo escrito produz um backup cujas duas metades discordam, e a discordância aparece semanas depois como arquivos que existem no disco mas não na interface, ou entradas na interface que apontam para nada. A correção direta é colocar a instância em modo de manutenção, exportar o banco de dados, capturar o diretório de dados, e desligar o modo de manutenção — o que é uma pequena interrupção que ninguém percebe às quatro da manhã. A documentação de backup detalha a sequência, e um snapshot de sistema de arquivos tirado com a aplicação parada alcança a mesma coisa em menos tempo, se o seu armazenamento suportar um.

Depois, mande para outro lugar, criptografado antes de sair. O Restic ou o Borg criptografam ambos no lado do cliente e deduplicam bem contra um conjunto de dados que muda nas bordas, que é o formato de um servidor de arquivos. Torne o repositório remoto somente-anexação (append-only) para que um host comprometido não consiga apagar o seu próprio histórico — é isso que transforma um backup numa defesa contra ransomware, e não apenas contra um disco falho — e coloque a ponta distante numa jurisdição diferente da ponta próxima, já que uma cópia que pode ser apreendida na mesma ação que o original não é realmente uma segunda cópia. Guarde a frase-senha do repositório em algum lugar que não seja o servidor.

Os dois recursos que as pessoas confundem com backups merecem ser nomeados. Versões de arquivo e a lixeira são conveniências que vivem dentro da mesma instância, no mesmo disco, no mesmo banco de dados; elas recuperam lindamente uma sobrescrita acidental e não sobrevivem a absolutamente nada que aconteça com o servidor. Da mesma forma, os snapshots horários do provedor — que todo plano aqui inclui, com sete dias de retenção — são excelentes para desfazer uma atualização ruim e não são um backup fora do local, porque compartilham o destino da infraestrutura em que estão. Use os três. Confie naquele que está em outro lugar.

Por fim, ensaie a restauração, uma vez, enquanto nada está errado. Provisione um servidor descartável, restaure o banco de dados e o diretório de dados nele, corrija a entrada de trusted-domain no config.php, e faça login. Você vai descobrir alguma coisa — um módulo do PHP ausente, um usuário de banco de dados que você nunca anotou, uma chave de criptografia que morava em algum lugar que você esqueceu — e vai descobrir isso numa tarde em que custa uma hora, em vez de no dia em que custa o arquivo inteiro. Se a restauração também precisar de um rescan de arquivos para reconciliar a árvore, é para isso que serve a ferramenta de linha de comando, e saber disso com antecedência é o ponto inteiro do exercício.

Compartilhando para fora sem vazar para dentro

O recurso que torna isso genuinamente útil para outras pessoas é também o que coloca uma URL para os seus arquivos na internet pública, então vale a pena gastar cinco minutos de configuração deliberada em vez de usar os padrões. Links públicos deveriam ter senha e expiração como questão de política, e não como decisão individual por link — os dois podem ser impostos para toda a instância, o que significa que a configuração é feita uma vez por você, em vez de esquecida toda vez por outra pessoa. Pastas de recebimento somente para upload são o caso subestimado: um link que aceita arquivos sem revelar o que já está na pasta substitui todo aquele fluxo desajeitado de anexo de e-mail que você tem hoje.

Atrás de um proxy reverso — que é como quase todo mundo roda isso — um único valor de configuração causa uma quantidade desproporcional de confusão. Se a aplicação não é informada de quais endereços confiar como proxies, cada requisição parece se originar do próprio proxy. A limitação de taxa então conta o mundo inteiro como um único visitante, a proteção contra força bruta eventualmente limita esse único endereço, e o efeito é uma instância que misteriosamente fica lenta ou bloqueia usuários legítimos enquanto os logs mostram um único IP fazendo tudo. Configurar a lista de proxies confiáveis e a sobreposição de protocolo, como descreve a documentação de proxy reverso, resolve os logs e a proteção numa linha cada.

A lista de trusted-domains é o outro valor que vale a pena entender em vez de simplesmente copiar. É uma lista de permissão de hostnames nos quais a instância vai responder, e ela existe porque a aplicação constrói URLs absolutas — links de redefinição de senha, links de compartilhamento, callbacks de federação — a partir do cabeçalho host que recebe. Deixada aberta, essa é uma forma bem conhecida de fazer os seus próprios links apontarem para outro lugar. Adicione os hostnames que você realmente usa, incluindo o endereço onion se você publicar um, e mais nada.

Se parte disso não deveria ser alcançável pela internet aberta de jeito nenhum, não resolva isso com uma regra de firewall e uma esperança. Existem duas respostas limpas: colocar a instância atrás de um túnel WireGuard para que ela só seja alcançável a partir de dispositivos que tenham uma chave, o que funciona bem para um arquivo pessoal e mal para compartilhar com pessoas de fora; ou publicá-la como um serviço onion ao lado do hostname clearnet, o que mantém os clientes de sincronização funcionando via Tor sem expor um endereço de jeito nenhum. As duas são aditivas — você pode rodar qualquer uma delas ao lado de um hostname público normal e deixar o material sensível viver atrás do caminho privado.

Quando você não deveria auto-hospedar isso

Um guia que nunca diz isso está vendendo alguma coisa, então aqui está a lista. Se os dados pertencem a uma empresa cujas operações param quando o servidor de arquivos para, você está subscrevendo uma garantia de disponibilidade com uma máquina e a atenção de uma pessoa, e um único VPS não é o instrumento certo para isso. Alta disponibilidade para essa aplicação é genuinamente complexa — armazenamento compartilhado, um banco de dados replicado, um balanceador de carga que entende sessões fixas (sticky sessions) — e se você precisa disso, você precisa de um orçamento e de uma segunda pessoa, não de um plano maior.

Se ninguém vai fazer a manutenção mensal, não comece. O trabalho é pequeno — aplicar atualizações, dar uma olhada na visão geral da administração, confirmar que o backup rodou, atualizar uma versão principal de cada vez quando uma nova sai — mas ele é implacável quando pulado por um ano. Uma instância várias versões principais atrasada não pode ser atualizada num único passo e não deveria estar voltada para a internet nesse meio-tempo, e escapar dessa posição é mais trabalho do que a manutenção teria sido.

Se a sua biblioteca é medida em terabytes e crescendo, o formato está errado, não o tamanho. Nenhum nível de VPS que vendemos chega a um terabyte de NVMe local, e acoplar armazenamento de objetos por trás da instância move o problema em vez de resolvê-lo: o banco de dados se torna ainda mais crítico, a latência em cada operação de arquivo aumenta, e você reintroduziu discretamente um terceiro num design cujo propósito inteiro era remover um. Compre hardware dedicado com discos espelhados, ou aceite que o arquivo e o hub de sincronização são dois sistemas diferentes.

E se o que você realmente quer é o Google Docs — trinta pessoas digitando na mesma planilha com cursores em menos de um segundo — seja honesto de que o stack de escritório auto-hospedado é bom, não equivalente, e que ele quer a sua própria memória e a sua própria CPU. Rode-o porque você quer os documentos no seu próprio disco, não porque você espera que a colaboração pareça idêntica.

Para todo mundo mais — uma família cansada de pagar aluguel pelas próprias fotografias, uma equipe pequena que prefere não ter seus contratos indexados por uma empresa com um departamento de políticas, um indivíduo que simplesmente quer que os arquivos estejam num lugar que ele escolheu — isso é uma das coisas mais gratificantes que você pode colocar num servidor. O software é maduro, os clientes são bons, os modos de falha são documentados, e o único genuinamente implacável é o backup que nunca foi testado. Um servidor leva cerca de um minuto para ser provisionado, as pré-visualizações ainda vão estar sendo geradas enquanto você termina de configurar os celulares, e você pode pagar por ele com a mesma postura de privacidade pela qual você está comprando.

Respostas rápidas

Perguntas frequentes

De quanto disco o Nextcloud realmente precisa?
Pegue a biblioteca que você genuinamente pretende sincronizar e acrescente cerca de vinte por cento para pré-visualizações geradas, versões de arquivo e uma lixeira que guarda arquivos excluídos por até trinta dias. A aplicação em si, o banco de dados e os caches juntos respondem por bem menos de dez gigabytes. Documentos raramente são o problema; o rolo de câmera do celular é, com algo entre quinze e quarenta gigabytes por pessoa por ano, incluindo vídeo, então uma casa que ativa o upload automático deveria planejar para isso chegando todo ano, quer alguém pense nisso quer não.
Eu consigo rodar isso no VPS mais barato?
Sim, para uma ou duas pessoas com uma biblioteca modesta — um plano de 4 GB roda a aplicação, um banco de dados de verdade e o Redis sem esforço, porque a carga é de I/O, não de CPU. A restrição limitante são os sessenta gigabytes de disco do nível de entrada, que um único rolo de câmera vai consumir em menos de dois anos. Se você já sabe que a biblioteca é maior do que isso, comece um nível acima: mover uma instância já povoada depois é mais trabalho do que pagar alguns dólares a mais agora.
O SQLite é realmente assim tão ruim?
Para qualquer coisa além de uma demonstração, sim. O SQLite serializa escritas em todo o banco de dados, e essa aplicação escreve em quase toda requisição — consultas de clientes, escaneamentos de arquivos, entradas de atividade — então, com dois clientes de sincronização ativos, as requisições começam a entrar numa fila umas atrás das outras e a interface adquire uma lentidão que nenhum ajuste remove. Instale o MariaDB ou o PostgreSQL desde o início. Converter uma instância já povoada depois é possível, documentado e inteiramente evitável.
A criptografia ponta a ponta quebra a interface web?
Dentro das pastas em que você a aplica, sim, e isso é a garantia, não um defeito. O servidor armazena texto cifrado que não consegue abrir, então não há visualização web, nem busca no lado do servidor, nem miniaturas, nem compartilhamento público para esse conteúdo, e perder o mnemônico significa perder os arquivos. Use-a para o material específico que precisa permanecer ilegível para o servidor e para o seu host, e deixe a biblioteca de fotos de fora dela, onde pré-visualizações e busca continuam funcionando.
Por que uploads grandes falham no navegador mas funcionam a partir do cliente de desktop?
Porque o cliente de desktop divide os uploads em pedaços e os remonta no servidor, então ele escapa por baixo de todos os limites de tamanho no caminho, enquanto o navegador envia uma única requisição grande que precisa sobreviver aos limites de upload e post size do PHP, ao tamanho máximo de corpo do servidor web e a qualquer timeout no meio do caminho. Se arquivos grandes entram na sua instância pelo navegador, todos esses valores precisam ser aumentados juntos — aumentar apenas um simplesmente muda qual componente recusa a requisição.
Eu deveria usar armazenamento de objetos em vez de disco local?
Só se você tiver um motivo maior do que ficar sem espaço. Armazenamento de objetos como armazenamento primário funciona, mas coloca uma ida e volta de rede na frente de cada operação de arquivo, torna o banco de dados a única autoridade sobre o que existe, e reintroduz exatamente o terceiro cuja remoção era o ponto da auto-hospedagem. Se a biblioteca já superou um VPS, discos espelhados em hardware dedicado mantêm os dados num metal que você aluga sozinho. Se mesmo assim você usar armazenamento de objetos, esse é o único caso em que a criptografia no lado do servidor justifica a sua sobrecarga.
Versões e a lixeira contam como backup?
Não. Ambos vivem dentro da mesma instância, no mesmo disco, referenciados pelo mesmo banco de dados, e recuperam muito bem uma sobrescrita ou exclusão acidental. Eles não sobrevivem a nada que aconteça com o próprio servidor. O mesmo vale para os snapshots horários incluídos em todo plano aqui: excelentes para desfazer uma atualização ruim, não uma cópia fora do local, porque compartilham o destino da infraestrutura em que estão. O backup que conta é criptografado antes de sair, armazenado de forma somente-anexação em outro lugar, e restaurado pelo menos uma vez.
O meu host consegue ler os meus arquivos?
Tecnicamente, qualquer um com acesso físico a uma máquina em funcionamento consegue alcançar os dados nela — isso é verdade para todo provedor de hospedagem, incluindo este, e qualquer provedor que afirme o contrário está descrevendo uma política, não um mecanismo. O que muda a resposta é arquitetura, não promessas: criptografia de disco inteiro significa que um disco desligado não rende nada, e criptografia ponta a ponta significa que os próprios arquivos são texto cifrado que o servidor nunca conseguiu abrir. Combine as duas nas pastas que importam e a pergunta deixa de depender de confiança.
Aplicar isto

Cargas de trabalho abordadas neste guia

Cada card abre uma página específica por carga de trabalho com recomendações de dimensionamento e FAQ de sysadmin.

Continue lendo

Outros guias

Leituras complementares que retomam onde esta termina.

Checklist de segurança Checklist de hardening de VPS: os primeiros 15 minutos em um servidor novo

Checklist de hardening de VPS: os primeiros 15 minutos em um servidor novo

As oito mudanças que realmente reduzem o risco de um VPS novo, na ordem certa para aplicá-las — porque se trancar para fora é bem mais provável do que ser invadido.

16 min de leitura Ler guia
Passo a passo de hardening Criptografia de disco completo em um VPS: LUKS, desbloqueio remoto e o que uma apreensão realmente recupera

Criptografia de disco completo em um VPS: LUKS, desbloqueio remoto e o que uma apreensão realmente recupera

Criptografar o disco de um servidor alugado vale a pena e não faz o que a maioria das pessoas pensa que faz. Onde fica a linha entre uma máquina desligada e uma em execução, como instalar uma raiz criptografada e desbloqueá-la via SSH, e o que a imagem de um disco realmente revela.

14 min de leitura Ler guia
Guia de entregabilidade Servidor de e-mail próprio em VPS: porta 25, DNS reverso e por que o e-mail cai no spam

Servidor de e-mail próprio em VPS: porta 25, DNS reverso e por que o e-mail cai no spam

Servidor de e-mail em VPS: fácil de instalar, difícil de entregar. O que os provedores checam primeiro, por que o IP pesa mais, e como alinhar SPF, DKIM e DMARC.

15 min de leitura Ler guia
Guia de migração Migrar para um novo VPS sem downtime: o corte, o DNS e o rollback

Migrar para um novo VPS sem downtime: o corte, o DNS e o rollback

A ordem de operações que leva um servidor ativo a um novo host em segundos de downtime, e não um fim de semana — mais o caminho de emergência para quando o provedor antigo já desligou tudo.

21 min de leitura Ler guia
Auxílio de decisão Escolhendo uma jurisdição: Islândia, Países Baixos, Romênia, Suíça

Escolhendo uma jurisdição: Islândia, Países Baixos, Romênia, Suíça

Uma comparação direta de nossos quatro locais offshore nas dimensões que realmente importam — tolerância a DMCA, lei de retenção de dados, alcance de peering, latência e preço.

8 min de leitura Ler guia

Leu o suficiente? Implantar em 60 segundos

Sem verificação de e-mail, sem ID, sem conta. Escolha um plano, pague em qualquer criptomoeda, receba o root.