De acordo com isso , você pode usar a variável de ambiente RESTIC_PASSWORD para especificar a senha.

Como @pvgoran já disse, você pode usar a variável de ambiente RESTIC_PASSWORD . Isso está documentado no manual aqui http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository. Se você tiver uma ideia sobre como documentar isso melhor, crie uma solicitação pull.

Há também o problema nº 278, que é sobre como ler a senha de um arquivo.

Vou encerrar este problema, pois não há nada que possamos fazer agora. Se você discordar, por favor deixe um comentário.

Ai, e pensei ter lido aquela seção inteira ....

Talvez dê a esse parágrafo seu próprio título ou subtítulo? Os primeiros quatro parágrafos dessa seção cobrem tudo sobre como inicializar um repositório. Automatizar backups não se encaixa nisso.

Obrigado @pvgoran pela resposta rápida, aliás. :sorriso:

Apenas uma rápida pergunta de acompanhamento sobre isso. Se um backup não terminar no momento em que o cron executar o restic novamente, o que acontecerá?

Neste caso, o restic iniciará um segundo backup (paralelo), que usa os dados já carregados pelo primeiro backup (ainda em execução). Acho que os dois backups serão concluídos quase ao mesmo tempo. Haverá alguma duplicação de dados, que será limpa quando o comando prune for executado na próxima vez. No entanto, isso não causará corrupção ou perda de dados. O formato do repositório é projetado de forma a permitir o upload paralelo de dados.

Este é um caso interessante sobre o qual ainda não pensei. Você acha que precisamos de um código para verificar se o mesmo backup já está sendo executado no mesmo host e sair neste caso?

@ fd0 Possivelmente, sim. Apenas para o mesmo backup. Ou uma maneira limpa de criar scripts de backups automatizados: algumas instruções servirão, talvez "backup restic", "restic unlock" e "restic prune", por exemplo. Mas não ter que se preocupar com esses comandos extras seria bom.

restic backup seguido por restic forget e restic prune é o fluxo de trabalho normal, e isso o limpa. Vou adicionar outro problema de qualquer maneira, para que possamos rastrear essa ideia.

Legal, obrigado! Por enquanto, vou usar esse fluxo.

Outra opção aqui que pode ajudar é um parâmetro de tempo limite. Se você souber que seu cron job agenda um backup a cada X horas, pode passar um --timeout para restic, de forma que ele termine antes que o próximo comece. Também seria útil para outras coisas. (isso pode já existir, sou novo no restic)

Detectar que o Restic já está em execução parece complicado e não sei como isso seria feito de forma precisa e limpa dentro do próprio Restic. Especialmente porque você pode ter diferentes backups restic rodando ao mesmo tempo, o que não deveria contar.

Talvez um script de inicialização que seja semelhante a muitos dos outros scripts de inicialização do Linux que pega o PID do restic quando é iniciado e o salva em um arquivo tmp e o apaga quando o restic termina. Cada vez que o script é executado, ele verifica o arquivo. Você precisaria de um arquivo tmp diferente para cada backup agendado exclusivo.

Infelizmente, qualquer meio de detectar uma instância do Restic em execução falhará em TODOS os back-ends (SFTP, REST, S3 ...), exceto o local.

@zcalusic , poderíamos usar as informações armazenadas nos arquivos de bloqueio para fazer isso: https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, talvez adicionar a lista de arquivos para fazer backup ou os argumentos exatos da linha de comando ou algo semelhante.

Eu ainda não vejo como o restic na máquina A, encontrando um bloqueio na máquina do servidor de backup B, distinguiria entre a) a sessão do restic em execução na máquina C eb) o bloqueio obsoleto deixado após o restic na máquina C travar?

Ou estamos começando a falar sobre mecanismos RPC aqui? Ou, melhor ainda, gerenciadores de bloqueio distribuídos? 😄

@zcalusic Estou falando sobre # 711: detectar quando um segundo backup com os mesmos diretórios na mesma máquina é iniciado. Isso deveria ser possível.

@bwmarrin Não entendo o que você está sugerindo:

Se você souber que seu cron job agenda um backup a cada X horas, pode passar um --timeout para restic, de forma que ele termine antes que o próximo comece.

Um backup é executado até o final ou é cancelado / encerrado. Não acho que seja possível cronometrar um backup que leva no máximo a duração dada em um parâmetro --timeout hipotético. Como isso poderia funcionar?

Você poderia descrever a semântica de tal parâmetro? Obrigado!

@ fd0 Estou dizendo que se o backup não terminar dentro do valor --timeout, ele será encerrado. Sei que isso significa que seria um backup incompleto ou inacabado. No entanto, como o design incremental do Restic não é grande coisa. Na próxima vez que o backup for chamado, ele começará de onde parou.

Isso significa que se você tem um cron job agendado para ser executado de hora em hora e passa um parâmetro --timeout 50m para o restic. Isso abortará / encerrará o backup se demorar mais de 50 minutos. Nesse caso, 10 minutos depois, o cron job o iniciará novamente e continuará de onde parou. Isso evitaria que várias instâncias do mesmo backup fossem executadas simultaneamente.

Obrigada pelo esclarecimento. Acho que não é uma boa ideia. O que acontece se o local do backup estiver lento sem que você perceba (alguém em sua rede esqueceu um cliente bittorrent, que maximiza sua largura de banda upstream), então o backup não termina, é abortado, reinicia novamente, é abortado novamente e assim por diante . Assim, você nunca terá um backup completo de trabalho.

Ou considere uma árvore de diretórios para a qual os dados são adicionados constantemente. Uma única execução do restic terminará eventualmente (é projetado dessa forma), mas reiniciá-lo pode nunca terminar quando muitos dados novos são adicionados entre as execuções.

Além disso, você pode implementar facilmente esse comportamento usando o utilitário padrão timeout (da coreutils), executando timeout 40m restic backup [...] . Portanto, não acho que adicionar essa opção ao Restic seja uma boa ideia.

Percebi que estou atrasado para a festa, mas não poderia haver um arquivo de bloqueio que faça a segunda instância esperar pela primeira terminar antes de começar?

@ Karl-Gustav, talvez você consiga isso com um pouco de script. https://stackoverflow.com/a/1985512/244009

Isso foi um pouco mais avançado do que minhas fechaduras :-) Eu apenas uso if file {wait 5sec and check again}

Posso chegar um pouco tarde para a discussão, mas criei algumas unidades do systemd que você pode encontrar aqui .
Estes são meus arquivos de configuração do Restic, eles podem ser úteis para alguém.

Olá, estou lendo sobre como usar o restic para agendar meus backups. Por enquanto, minha ideia é usar o anacron para agendar, por exemplo, um backup de 2 dias por semana para o Backblaze. O que quero dizer é que se meu backup estiver agendado com anacron, por exemplo, terça e sexta-feira às 12h e meu laptop estiver desligado na terça e não reiniciá-lo até sexta-feira, digamos, 11h59, o que acontecerá? AFAIK (e se não estou errado) anacron deve iniciar o trabalho perdido de terça-feira; e um minuto depois (enquanto a primeira instância do restic está em execução), o segundo backup será executado, produzindo 2 backups simultâneos para o mesmo diretório?

Ou é qualquer tipo de arquivo de bloqueio / tmp para impedir a execução da segunda instância?
Como devo gerenciá-lo para agendar corretamente meu backup? THX :)

@gerardbosch Olá! Esta questão é mais adequada para o fórum , considere isso da próxima vez :)

Uma maneira de lidar com isso é escrever um script que executa o restic para você e, como parte disso, cria um arquivo de execução (por exemplo, /var/run/restic.pid contendo o PID do processo restic`), que pode então verifique se o Restic já está funcionando ou não.

Não será harm forma alguma se você executar dois backups simultâneos, mas é claro que é inútil se eles cobrirem mais ou menos os mesmos arquivos e momentos específicos.

Se o anacron tenta recuperar as execuções de backup perdidas, eu não sei, ele deve dizer em sua documentação, suponho. Se você está no macOS e usa launchd para agendamento, tem a opção de fazer isso ou não, você decide.

Para sua informação, para mais pessoas vindo das pesquisas do Google:

Aqui está como faço backup em uma programação usando serviços e horários do systemd, em vez de tarefas cron. Também apresenta notificações por e-mail quando o backup falha.

https://github.com/erikw/restic-systemd-automatic-backup

@erikw Script de programação fantástico, parabéns!
Algumas perguntas:

• Qual é a principal vantagem de usar cronômetros systemd em vez de cron ou anacron?
• Os scripts / configuração do systemd podem ser instalados no homedir em vez de / etc?
• A guia anacron pode residir em algum lugar em $ HOME?

Estou planejando fazer backup do homedir do meu laptop, portanto, fazer backup dos mesmos scripts do agendador fornecerá, em caso de recuperação de desastre, um sistema de backup agendado pronto para uso (ou seja, restaurar todo o backup após o desastre, fornecerá um nova conta de usuário já configurada para fazer backup na mesma programação anterior).

@gerardbosch

• Se você tem um sistema systemd, é muito bom poder usar as ferramentas padrão, sem a necessidade de instalar um daemon cron. Você obtém grande controle sobre o status de trabalhos com falha e pode ver quando um trabalho será executado na próxima vez, por exemplo. Veja o arch wiki para uma breve introdução. Mas brincar com isso é a maneira mais divertida de aprender, eu diria.

• Sim, eu executo vários cronômetros do systemd para meu usuário local. Verifique meus dotfiles para os temporizadores e serviços correspondentes que uso atualmente. A chave é usar --user para controlar os cronômetros do usuário em vez dos cronômetros do sistema:

$ systemctl --user list-timers

• Parece que eles estão em /var/spool normalmente. Se o pode ser movido para ~/ não sei. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

Como não foi mencionado aqui ainda, Backupninja é uma ótima maneira de lidar com o agendamento. O suporte Restic está sendo adicionado em uma solicitação de mesclagem ; apenas não foi confirmado ainda. Todas as funcionalidades básicas devem estar lá.

@colans Backupninja é incrível, mal posso esperar para poder usá-lo com o Restic! Obrigado por este trabalho.

restic backup seguido por restic forget e restic prune é o fluxo de trabalho normal, e isso o limpa. Vou adicionar outro problema de qualquer maneira, para que possamos rastrear essa ideia.

Se eu estiver configurando uma tarefa / cron job agendada diariamente sem a expectativa de possíveis jobs paralelos, o script ainda deve fazer restic backup -> restic forget -> restic prune ? Parece que está adicionando mais sobrecarga se estivermos executando apenas uma instância por vez

Podemos reabrir isso como uma tarefa de documentação? Acho que devemos adicionar uma seção "Agendamento" ao manual para aumentar a clareza em torno deste tópico. Podemos dizer algo como:

O agendamento está fora do escopo da Restic. No entanto, existem ferramentas externas que podem ser usadas para esse fim.

• Backupninja junto com a filial de suporte Restic
• Backups restic automáticos usando serviços e temporizadores systemd
• Restic backup configs

Pensamentos?

Outras sugestões para reabrir. Se o restic não suportar o agendamento / monitoramento de backup, os documentos podem explicar isso e fazer um link para algo que suporte, já que essa é a principal forma de usar as ferramentas de backup.

@SigmaX como agendar depende inteiramente de qual sistema operacional e software você tem à sua disposição. Acho que sugestões como essa estão fora da documentação para preocupação restrita, mas poderia ser um artigo útil no blog de alguém ou mesmo na seção de Receitas do fórum. Também poderia ser um candidato para a seção de exemplos no site do restic doc em https://restic.readthedocs.io/en/latest/080_examples.html , mas teria que ser escrito de forma a exigir um mínimo de manutenção, já que não queremos manter um conjunto de instruções detalhadas sobre como agendar isso em várias plataformas diferentes (já que é um tópico bastante complexo). Dito isso, já existem vários artigos e exemplos sobre isso (por exemplo, com cron e systemd) na rede, se alguém pesquisar por ele. Não tenho certeza se há necessidade de ter isso no site de documentos.

Não tenho certeza se há necessidade de ter isso no site de documentos.

Posso ver como seria uma questão de opinião, especialmente porque o restic é multiplataforma. Para mim, foi surpreendente. Ter uma ferramenta de backup sem documentos importantes sobre como agendar parece-me como vender um carro sem rodas. Passei um bom tempo procurando nos documentos, presumindo que estava faltando alguma coisa. Eu nunca iniciaria um backup manualmente, mas isso é tudo o que os documentos descrevem.

No mínimo, uma seção de documentos pode economizar o tempo dos usuários: ao indicar que eles precisam pesquisar em outro lugar / encontrar uma ferramenta diferente para configurar backups de rotina com restic.

Ter uma ferramenta de backup sem documentos importantes sobre como agendar parece-me como vender um carro sem rodas

Na verdade não. O que "vendemos" a você é um programa que diz o que fazer backup e ele faz o backup. A frequência com que você deseja fazer isso é uma preocupação separada :) Mas estou divagando.

Eu esperaria que a maioria dos usuários, se não encontrando um determinado tópico na documentação, simplesmente fizesse DDG / Google para isso e encontrasse as respostas em um ou dois minutos. Mas isso não significa que não devemos adicionar um ponteiro de algum tipo à documentação, mesmo se não detalharmos os detalhes sobre como configurar vários softwares de agendamento.

O que "vendemos" a você é um programa que diz o que fazer backup e ele faz o backup. A frequência com que você deseja fazer isso é uma preocupação separada :)

E é perfeitamente legítimo dizer "este é um kit DIY --- vá encontrar suas próprias rodas!"

Eu esperaria que a maioria dos usuários, se não encontrando um determinado tópico na documentação, simplesmente fizesse DDG / Google para isso e encontrasse as respostas em um ou dois minutos.

Na verdade, pesquisar no Google por "agendamento de backup restic" me trouxe aqui a primeira correspondência: sorriso:

2122 está relacionado, pois fornece alguns timers do systemd de amostra e outras discussões sobre programação.

Acho que a abordagem de "menos manutenção" aqui parece fazer sentido ... talvez incluir dicas sobre a saída de log e evitar várias execuções ao mesmo tempo?

talvez inclua dicas sobre como registrar a saída e evitar várias execuções ao mesmo tempo?

Eu gosto daquela ideia. Farei um rascunho ainda esta semana, provavelmente para uma pequena seção de "indicação" para colocar sob a seção de backup na documentação.