에 따르면 이 , 당신은 암호를 지정하는 환경 변수 RESTIC_PASSWORD를 사용할 수 있습니다.

@pvgoran이 이미 말했듯이 환경 변수 RESTIC_PASSWORD 사용할 수 있습니다. 이것은 http://restic.readthedocs.io/en/latest/Manual/#initialize -a-repository의 매뉴얼에 문서화되어

파일에서 암호를 읽는 문제 # 278도 있습니다.

지금 당장해야 할 일이 없으므로이 문제를 해결하겠습니다. 동의하지 않는 경우 댓글을 남겨주세요.

아야, 나는 그 섹션을 읽었다 고 생각했다 ....

해당 단락에 자체 제목 또는 부제목을 제공 할 수 있습니까? 이 섹션의 처음 네 단락은 저장소 초기화에 대한 모든 것을 다룹니다. 백업 자동화는 그에 맞지 않습니다.

빠른 답변, btw에 대해 @pvgoran 에게 감사드립니다. :미소:

이것에 대한 간단한 후속 질문입니다. cron이 restic을 다시 실행할 때까지 백업이 완료되지 않으면 어떻게됩니까?

이 경우 restic은 첫 번째 (아직 실행중인) 백업에서 이미 업로드 된 데이터를 사용하는 두 번째 (병렬) 백업을 시작합니다. 두 백업이 거의 동시에 완료 될 것 같습니다. 다음 번에 prune 명령이 실행될 때 정리되는 일부 데이터 중복이 있습니다. 그러나 데이터 손상이나 데이터 손실은 발생하지 않습니다. 저장소 형식은 데이터의 병렬 업로드를 허용하는 방식으로 설계되었습니다.

이것은 내가 아직 생각하지 않은 흥미로운 사례입니다. 동일한 백업이 동일한 호스트에서 이미 실행 중인지 확인하고이 경우 종료하는 코드가 필요하다고 생각하십니까?

@ fd0 아마도 그렇습니다. 동일한 백업에만 해당됩니다. 또는 자동화 된 백업을 스크립팅하는 깔끔한 방법 : 예를 들어 "restic backup", "restic unlock", "restic prune"순으로 수행 할 수 있습니다. 그러나 이러한 추가 명령에 대해 걱정할 필요가없는 것이 좋습니다.

restic backup 다음에 restic forget 및 restic prune 이 (가) 일반적인 워크 플로이며 정리됩니다. 어쨌든이 아이디어를 추적 할 수 있도록 다른 문제를 추가하겠습니다.

감사합니다! 지금은 그 흐름을 사용하겠습니다.

도움이 될 수있는 또 다른 옵션은 시간 초과 매개 변수입니다. 크론 작업이 X 시간마다 백업을 예약한다는 것을 알고 있다면 --timeout을 restic에 전달하여 다음 작업이 시작되기 전에 종료되도록 할 수 있습니다. 다른 것들에도 유용 할 것입니다. (이미 존재할 수 있음, 나는 restic을 처음 사용합니다)

restic이 이미 실행되고 있음을 감지하는 것은 까다로운 소리이며 restic 자체에서 정확하고 깔끔하게 수행되는 방법이 아닙니다. 특히 중요하지 않은 동시에 다른 restic 백업을 실행할 수 있기 때문입니다.

아마도 다른 많은 리눅스 시작 스크립트와 유사한 시작 스크립트는 시작될 때 restic의 PID를 취하고 그것을 tmp 파일에 저장 한 다음 restic이 끝나면 삭제합니다. 스크립트가 실행될 때마다 파일을 확인합니다. 고유 한 예약 된 백업마다 다른 tmp 파일이 필요합니다.

불행히도 실행중인 restic 인스턴스를 감지하는 모든 방법은 로컬 인스턴스를 제외한 모든 백엔드 (SFTP, REST, S3 ...)에서 실패합니다.

@zcalusic 우리는 잠금 파일에 저장된 정보를 사용하여 https://github.com/restic/restic/blob/master/src/restic/lock.go#L27 -L33, 파일 목록 추가 가능 백업 또는 정확한 명령 줄 인수 또는 이와 유사한 것.

나는 여전히 시스템 A에서 휴식을 취하고 백업 서버 시스템 B에서 잠금을 찾고 a) 시스템 C에서 현재 실행중인 휴식 세션과 b) 시스템 C의 휴식이 중단 된 후 남은 부실 잠금을 구분하는 방법을 알 수 없습니다.

아니면 여기서 RPC 메커니즘에 대해 이야기하기 시작합니까? 아니면 더 나은 분산 잠금 관리자? 😄

@zcalusic 저는 # 711에 대해 이야기하고 있습니다 : 동일한 머신에서 동일한 디렉토리를 가진 두 번째 백업이 시작될 때 감지합니다. 가능해야합니다.

@bwmarrin 당신이 제안하는 것을 이해하지 못합니다.

크론 작업이 X 시간마다 백업을 예약한다는 것을 알고 있다면 --timeout을 restic에 전달하여 다음 작업이 시작되기 전에 종료되도록 할 수 있습니다.

백업이 끝날 때까지 실행되거나 취소 / 종료됩니다. 가상의 --timeout 매개 변수에 주어진 기간에 관계없이 백업에 시간이 걸리는 백업 시간을 계산할 수 있다고 생각하지 않습니다. 어떻게 작동할까요?

그러한 매개 변수의 의미를 설명해 주시겠습니까? 감사!

@ fd0 백업이 --timeout 값 내에 완료되지 않으면 종료됩니다. 이것은 불완전하거나 완료되지 않은 백업이라는 것을 의미합니다. 그러나 restic의 점진적 디자인이므로 실제로 큰 문제는 아닙니다. 다음에 백업이 호출되면 중단 된 지점부터 시작됩니다.

즉, 매시간 실행되도록 예약 된 크론 작업이 있고 --timeout 50m 매개 변수를 restic에 전달합니다. 50 분 이상 걸리는 경우 백업을 중단 / 종료합니다. 이 경우 10 분 후 크론 작업이 다시 시작되고 중단 된 지점에서 다시 시작됩니다. 이렇게하면 동일한 백업의 여러 인스턴스가 동시에 실행되지 않습니다.

설명 해주셔서 감사합니다. 이것은 좋은 생각이 아니라고 생각합니다. 사용자가 알지 못하는 사이 백업 위치가 느려서 (네트워크의 누군가가 비트 토렌트 클라이언트를 잊어 버려 업스트림 대역폭이 최대가 됨) 백업이 완료되지 않고 중단되고 다시 시작되고 다시 중단되는 경우 어떻게됩니까? . 그러면 전체 작업 백업으로 끝나지 않습니다.

또는 데이터가 지속적으로 추가되는 디렉토리 트리를 고려하십시오. restic의 단일 실행은 결국 완료되지만 (그렇게 설계됨) 실행 사이에 너무 많은 새 데이터가 추가되면 restic을 다시 시작하면 완료되지 않을 수 있습니다.

또한 표준 유틸리티 timeout (coreutils에서)를 사용하고 timeout 40m restic backup [...] 실행하여이 동작을 쉽게 구현할 수 있습니다. 따라서이 옵션을 restic에 추가하는 것은 좋은 생각이 아닙니다.

파티에 늦었지만 두 번째 인스턴스가 시작되기 전에 첫 번째 인스턴스가 완료 될 때까지 기다리도록하는 잠금 파일이있을 수 없습니까?

@ Karl-Gustav는 약간의 스크립팅으로이를 달성 할 수 있습니다. https://stackoverflow.com/a/1985512/244009

그것은 내 자물쇠보다 조금 더 발전했습니다 .-) 저는 if file {wait 5sec and check again}

토론에 조금 늦었을 수 있지만 여기에서 찾을 수있는 시스템 단위를 만들었습니다.
이것들은 내 restic 구성 파일이며 누군가에게 유용 할 수 있습니다.

안녕하세요. restic을 사용하여 백업을 예약하는 방법에 대해 읽고 있습니다. 지금은 anacron을 사용하여 예를 들어 주당 2 일 Backblaze에 백업하도록 예약하는 것입니다. 요점은 화요일과 금요일 오후 12시에 anacron으로 백업을 예약하고 랩톱을 화요일에 끄고 금요일 오전 11시 59 분까지 다시 시작하지 않으면 어떻게됩니까? AFAIK (그리고 내가 틀리지 않았다면) anacron은 화요일에 놓친 일을 시작해야합니다. 1 분 후 (첫 번째 restic 인스턴스가 실행되는 동안) 두 번째 백업을 실행하여 동일한 디렉토리에 대해 2 개의 동시 백업을 생성합니까?

아니면 두 번째 인스턴스가 실행되는 것을 막기 위해 어떤 종류의 / tmp 잠금 파일입니까?
백업을 올바르게 예약하려면 어떻게 관리해야합니까? 고마워 :)

@gerardbosch 안녕하세요! 이 질문은 포럼에 더 적합합니다. 다음에 고려하십시오. :)

이를 처리하는 한 가지 방법은 restic을 실행하는 스크립트를 작성하는 것입니다.이 작업의 일부로 실행 파일 (예 : restic 프로세스의 PID를 포함하는 /var/run/restic.pid )을 생성합니다. restic이 이미 작동하는지 확인하십시오.

두 개의 동시 백업을 실행하는 경우 어떤 식 으로든 harm 가 아니지만 동일한 파일과 특정 시점을 어느 정도 포함한다면 당연히 의미가 없습니다.

anacron이 누락 된 백업 실행을 따라 잡으려고하는지 여부는 잘 모르겠지만 문서에 나와 있어야합니다. macOS를 사용 중이고 예약에 launchd 를 사용하는 경우 그렇게 할 것인지 여부를 선택할 수 있습니다.

더 많은 사람들이 Google 검색을 통해 여기에 도착하는 경우 참고 :

cron 작업 대신 systemd 서비스 및 시간을 사용하여 일정에 따라 백업을 수행하는 방법은 다음과 같습니다. 또한 백업 실패시 이메일 알림을 제공합니다.

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

@erikw 환상적인 일정 스크립트,
몇 가지 질문 :

• cron 또는 anacron보다 systemd 타이머를 사용하는 주요 이점은 무엇입니까?
• systemd 스크립트 / 설정을 / etc 대신 homedir에 설치할 수 있습니까?
• anacron 탭이 $ HOME 어딘가에있을 수 있습니까?

랩톱의 homedir을 백업 할 계획이므로 재해 복구시 동일한 스케줄러 스크립트를 백업하면 즉시 사용 가능한 예약 된 백업 시스템 (예 : 재해 후 전체 백업 복원)이 제공됩니다. 동일한 이전 일정으로 백업을 수행하도록 이미 구성된 새 사용자 계정).

뿡 빵뀨

• systemd 시스템을 가지고 있다면, cron 데몬을 설치할 필요없이 기본 도구를 사용할 수 있다는 것이 매우 좋습니다. 실패한 작업의 상태를 잘 제어 할 수 있으며 예를 들어 다음에 작업이 언제 실행되는지 확인할 수 있습니다. 짧은 소개는 아치 위키 를 참조하십시오. 직접 가지고 노는 것이 내가 말할 수있는 가장 재미있는 방법입니다.

• 예, 로컬 사용자를 위해 여러 개의 시스템 타이머를 실행합니다. 현재 사용중인 타이머 및 해당 서비스에 대한 내 dotfile 을 확인하십시오. 핵심은 시스템 타이머 대신 --user 를 사용하여 사용자의 타이머를 제어하는 ​​것입니다.

$ systemctl --user list-timers

• 보통 /var/spool 있는 것 같습니다. ~/ 옮길 수 있는지 모르겠습니다. https://askubuntu.com/questions/216692/where-is-the-user-crontab-stored

아직 여기에 언급되지 않았 으므로 Backupninja 는 예약을 처리하는 좋은 방법입니다. Restic 지원이 병합 요청 에 추가되고 있습니다. 아직 커밋되지 않았습니다. 하지만 모든 기본 기능이 있어야합니다.

@colans Backupninja는 굉장합니다. restic과 함께 사용할 수 있기를 기다릴 수 없습니다! 이 작업에 감사드립니다.

restic backup 다음에 restic forget 및 restic prune 이 (가) 일반적인 워크 플로이며 정리됩니다. 어쨌든이 아이디어를 추적 할 수 있도록 다른 문제를 추가하겠습니다.

가능한 병렬 작업을 기대하지 않고 매일 예약 된 작업 / 크론 작업을 설정하는 경우 스크립트가 restic backup -> restic forget -> restic prune ? 한 번에 하나의 인스턴스 만 실행하는 경우 더 많은 오버 헤드를 추가하는 것 같습니다.

이것을 문서화 작업으로 다시 열 수 있습니까? 이 주제에 대한 명확성을 높이기 위해 매뉴얼에 "스케줄링"섹션을 추가해야한다고 생각합니다. 다음과 같이 말할 수 있습니다.

예약은 Restic의 범위를 벗어납니다. 그러나 이러한 목적으로 사용할 수있는 외부 도구가 있습니다.

• Restic 지원 지점 과 함께
• 시스템화 된 서비스 및 타이머를 사용하여 자동 복원 백업
• Restic 백업 구성

생각?

다시 여는 또 다른 제안. restic이 백업 예약 / 모니터링을 지원하지 않는 경우, 문서는이를 설명하고 백업 도구가 사용되는 기본 방법이기 때문에 해당 작업에 연결할 수 있습니다.

@SigmaX 예약 방법은 전적으로 원하는 OS와 소프트웨어에 따라 다릅니다. 나는 그와 같은 제안이 불안한 우려에 대한 문서 외부에 있다고 생각하지만 실제로 누군가의 블로그 또는 포럼의 레시피 섹션에서 유용한 기사가 될 수 있습니다. 또한 restic doc 웹 사이트 https://restic.readthedocs.io/en/latest/080_examples.html 의 예제 섹션에 대한 후보가 될 수 있지만 최소가 필요한 방식으로 작성해야합니다. 여러 다른 플랫폼에서이를 예약하는 방법에 대한 자세한 지침을 유지하고 싶지 않기 때문입니다 (매우 복잡한 주제이므로). 즉, 인터넷에 이미 여러 기사와 예제 (예 : cron 및 systemd 사용)가 있습니다. 문서 웹 사이트에 필요한 것이 있는지 완전히 확신하지 못합니다.

문서 웹 사이트에 필요한 것이 있는지 완전히 확신하지 못합니다.

특히 restic은 크로스 플랫폼이기 때문에 어떻게 의견의 문제인지 알 수 있습니다. 저에게는 놀라운 일이었습니다. 예약 방법에 대한 저명한 문서가없는 백업 도구가 있으면 바퀴가없는 자동차를 판매하는 것처럼 들립니다. 나는 뭔가 빠졌다고 가정하고 문서를 검색하는 데 꽤 오랜 시간을 보냈다. 나는 수동으로 백업을 시작하지 않을 것이지만 그게 다 문서에 설명되어 있습니다.

최소한 문서 섹션은 사용자가 다른 곳을 검색해야 함을 나타내거나 restic으로 일상적인 백업을 설정하기 위해 다른 도구를 찾아야 함을 표시함으로써 사용자의 시간을 절약 할 수 있습니다.

예약 방법에 대한 저명한 문서가없는 백업 도구가 있으면 바퀴가없는 자동차를 판매하는 것처럼 들립니다.

별로. 우리가 "판매"하는 것은 무엇을 백업해야하는지 알려주고 백업하는 프로그램입니다. 얼마나 자주 그렇게하고 싶은지는 별개의 문제입니다.

문서에서 특정 주제를 찾지 못한 경우 대부분의 사용자는 단순히 DDG / Google을 사용하고 1 ~ 2 분 이내에 답변을 찾을 수 있습니다. 그러나 이것이 다양한 스케줄링 소프트웨어를 설정하는 방법에 대한 세부 사항을 자세히 설명하지 않더라도 문서에 어떤 종류의 포인터를 추가해서는 안된다는 의미는 아닙니다.

우리가 "판매"하는 것은 무엇을 백업해야하는지 알려주고 백업하는 프로그램입니다. 얼마나 자주 그렇게 하려는지는 별개의 문제입니다. :)

그리고 "이것은 DIY 키트입니다 --- 자신의 바퀴를 찾으십시오!"라고 말하는 것은 완벽하게 합법적입니다.

문서에서 특정 주제를 찾지 못한 경우 대부분의 사용자는 단순히 DDG / Google을 사용하고 1 ~ 2 분 이내에 답변을 찾을 수 있습니다.

사실, "restic backup schedule"에 대한 인터넷 검색은 저를 첫 번째 경기로 데려 왔습니다. : smile :

2122는 몇 가지 샘플 시스템 타이머 및 스케줄링에 관한 기타 논의를 제공하므로 관련이 있습니다.

여기에서 "최소 유지 관리"접근 방식이 의미가 있다고 생각합니다. 출력 로깅과 동시에 여러 실행을 방지하는 방법에 대한 힌트를 포함 할 수 있습니까?

출력 로깅과 동시에 여러 실행 방지에 대한 힌트를 포함 할 수 있습니까?

나는 그 생각을 좋아한다. 나는 이번 주 후반에 초안을 만들 것이며, 대부분 문서의 백업 섹션 아래에 작은 "포인터"섹션을 배치 할 것입니다.