O Immich é a resposta auto-alojada ao Google Fotos: o seu servidor, os seus discos, uma aplicação móvel que faz cópia do seu rolo de câmara. A instalação lê-se como se demorasse cinco minutos, e mecanicamente é assim mesmo. As decisões que determinarão se daqui a três anos ainda tem as suas fotos tomam-se todas no ficheiro que edita antes de a lançar.
O que é realmente a instalação oficial
Dois downloads e um comando. A documentação dá-os tal como estão:
wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml
wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env
Repare na assimetria dessa segunda linha: o ficheiro é publicado com o nome example.env e é guardado por si como .env. Depois, uma vez preenchidas as variáveis, toda a instalação se resume a docker compose up -d.
Se esse último comando falhar, a documentação nomeia a causa habitual antes de ter de a procurar. Avisa que, se obtiver um erro do tipo unknown shorthand flag: 'd' in -d, provavelmente não tem a versão certa do Docker, e que a forma correta é docker compose com um espaço em vez do antigo binário docker-compose. Assinala à parte uma segunda armadilha de versão: um erro que indica can't set healthcheck.start_interval as feature require Docker Engine v25 or later, que sugere contornar comentando essa linha.
São dois desencontros de versão, não erros no seu ficheiro. Nenhum deles merece uma noite.
Os dois locais que decidem a sua capacidade de recuperar
O ficheiro compose é curto, mas duas das suas variáveis não são definições intermutáveis. São a resposta a « o que devo salvaguardar » e « o que se vai corromper sozinho ».
UPLOAD_LOCATION é descrita na documentação como o local onde os seus ficheiros carregados são armazenados, com a indicação de aí colocar o local da sua preferência para conservar esses dados. É a pasta que conterá cada foto que carregar. Escolhê-la de ânimo leve é a forma mais comum de acabar com uma fototeca colocada fora de todas as cópias de segurança que já tem a correr.
DB_DATA_LOCATION é a base de dados, e a documentação associa-lhe uma restrição firme: as partilhas de rede não são suportadas para a base de dados. Não é uma recomendação de desempenho. Os motores de base de dados apoiam-se em garantias de bloqueio e de ordem de escrita que os sistemas de ficheiros em rede dão de forma desigual, e o modo de falha costuma ser uma corrupção silenciosa descoberta semanas depois, não uma recusa em arrancar.
Na prática: a sua fototeca pode viver em armazenamento de rede se aceitar que fique mais lenta. A pasta da base de dados fica num disco local. E seja qual for a sua escolha para a primeira, anote-a, porque é o caminho que as suas cópias têm de incluir.
O aviso que o projeto coloca na sua própria página inicial
A maioria dos guias de auto-alojamento passa-o ao lado, por isso vale a pena citar o projeto em vez de o parafrasear. O repositório do Immich traz, logo no topo, esta linha: « Always follow 3-2-1 backup plan for your precious photos and videos! »
Esse aviso faz algo de preciso. Não diz que o software seja pouco fiável. Diz que alojar o seu próprio servidor de fotos não é em si uma cópia de segurança, e quem o escreveu sabe que os auto-alojadores acreditam habitualmente no contrário. Uma instância única numa máquina única detém exatamente uma cópia da sua fototeca. Um disco que cede, uma atualização atabalhoada, uma eliminação acidental ou um caminho mal escrito fá-la desaparecer, e não há nenhum fornecedor a quem a pedir.
O projeto tem licença AGPL-3.0, o que explica em parte que o possa auditar e executar. Isso não muda a aritmética de ter uma só cópia.
O que o auto-alojamento desloca, e o que não
O auto-alojamento é muitas vezes apresentado como a opção privada, e ponto. É mais exato, e mais útil, dizer que desloca a confiança em vez de a eliminar.
O que muda a sério: nenhuma empresa detém a sua fototeca, nenhum fornecedor pode ser obrigado legalmente a entregá-la, nenhuma condição de utilização muda nas suas costas e não há conta nenhuma para perder. Para muita gente é esse todo o sentido da coisa, e o ganho é real.
O que não muda por si só: a cifragem em repouso nos seus próprios discos, a segurança física da máquina, mantê-la atualizada e ter mais do que uma cópia. Tudo isso passa a ser o seu trabalho no momento em que o tira a um fornecedor. É essa a troca, e é razoável aceitá-la de forma consciente. É bem menos razoável aceitá-la por distração, por se ter suposto que auto-alojado queria dizer protegido.
Quer a fototeca privada sem administrar o servidor? pCloud vitalício + Crypto
Jurisdição suíça · Zero-knowledge com a opção Crypto · Pagamento único, sem atualizações a seguir nem base de dados a salvaguardar
Escolher honestamente entre as duas
Auto-aloje o Immich se quiser as suas fotos em hardware que controla, se aceitar assumir as cópias de segurança e as atualizações, e se a manutenção lhe interessar em vez de lhe pesar daqui a oito meses.
Use um serviço gerido zero-knowledge se o que queria realmente era que nenhuma empresa pudesse ler as suas fotos, sem passar a ser a pessoa de piquete no dia em que o disco falhar. Esse resultado obtém-se sem servidor, e escolhê-lo não é uma cedência em matéria de privacidade: é uma repartição diferente do mesmo trabalho.
A única resposta que não sobrevive ao contacto com a realidade é uma instância auto-alojada única sem segunda cópia. É exatamente por isso que o projeto o diz ele próprio antes de instalar seja o que for.
Os comandos de instalação, a precisão de que o ficheiro de ambiente é publicado com o nome example.env, as descrições de UPLOAD_LOCATION e DB_DATA_LOCATION, a afirmação de que as partilhas de rede não são suportadas para a base de dados, e os dois erros de versão do Docker provêm da documentação oficial de instalação do Immich com Docker Compose. A linha sobre a cópia 3-2-1 e a licença AGPL-3.0 provêm da página inicial do repositório do projeto. As citações ficam na língua original. Ambas as fontes foram consultadas no momento da redação; verifique na versão que está a instalar, já que o ficheiro compose é distribuído com cada release. As ligações comerciais levam o atributo rel="sponsored nofollow"; pode aplicar-se uma comissão de afiliação, sem custo adicional para si.
Guias relacionados
- Melhor armazenamento na nuvem para fotos - a vertente gerida da mesma pergunta, com os serviços que cifram as fotos do lado do cliente.
- Armazenamento na nuvem auto-alojado - a mesma troca aplicada aos ficheiros em vez das fotos, com Nextcloud, Seafile e ownCloud.
Perguntas frequentes
- O que é preciso descarregar realmente para instalar o Immich?
- Dois ficheiros, publicados com cada versão. A documentação dá os comandos tal como estão: wget -O docker-compose.yml https://github.com/immich-app/immich/releases/latest/download/docker-compose.yml e wget -O .env https://github.com/immich-app/immich/releases/latest/download/example.env. Repare que o segundo é publicado com o nome example.env e que o guarda como .env. Depois de preenchidas as variáveis, toda a instalação cabe num comando: docker compose up -d.
- Porque falha o meu comando docker compose com um erro de opção desconhecida?
- Está quase de certeza a usar o antigo binário autónomo em vez do plugin. A documentação trata este caso de forma explícita: se obtiver um erro do tipo unknown shorthand flag 'd' in -d, provavelmente não tem a versão certa do Docker, e o comando correto é docker compose, com um espaço, e não docker-compose com hífen. Menciona à parte uma segunda armadilha de versão: um erro a indicar que healthcheck.start_interval exige o Docker Engine v25 ou posterior, que sugere contornar comentando essa linha.
- Onde acabam realmente as minhas fotos no disco?
- Onde apontar UPLOAD_LOCATION, que a documentação descreve como o local onde os seus ficheiros carregados são armazenados, pedindo-lhe que indique aí o local da sua preferência para conservar esses dados. É a linha de maior consequência do ficheiro, porque decide qual a pasta que terá de incluir nas cópias de segurança. Defina-a deliberadamente para um caminho que já protege, em vez de aceitar um valor por omissão e descobrir mais tarde que a sua fototeca vive num sítio para onde as suas cópias nunca olham.
- Posso pôr a base de dados no meu NAS?
- A base de dados não. A documentação di-lo sem rodeios para DB_DATA_LOCATION: as partilhas de rede não são suportadas para a base de dados. As bases de dados precisam de bloqueio de ficheiros de baixo nível que os sistemas de ficheiros em rede não garantem de forma fiável, e ignorá-lo costuma produzir corrupção em vez de um erro limpo. A sua fototeca pode viver em armazenamento de rede se aceitar o custo em desempenho; a pasta da base de dados fica num disco local.
- Basta auto-alojar o Immich para pôr as fotos a salvo?
- O próprio projeto diz que não, e di-lo na sua própria página inicial: siga sempre um plano de cópias 3-2-1 para as suas fotos e vídeos preciosos. Executar o servidor você mesmo muda quem detém a sua fototeca, não cria uma segunda cópia dela. Uma instância auto-alojada numa só máquina está a uma falha de disco, a uma atualização mal feita ou a uma eliminação acidental da perda total, que é exatamente o que a regra 3-2-1 existe para evitar.
Obter pCloud
Garantia de devolução de dinheiro em 10 dias
