Restic: 암호화되지 않은 백업

나는 이 기능 요청을 지금 몇 번 들었고 그것에 대해 문제가 있다는 것을 염두에 두었습니다. 찾을 수 없는 것 같아서 이 기능 요청을 여기에서 추적합니다. 짧은 버전은 다음과 같습니다. 언젠가는 결국 암호화를 비활성화하는 옵션을 추가할 수 있지만 현재 로드맵에는 없습니다.

긴 버전은 다음과 같습니다.

• 암호화는 더 이상 비싸지 않습니다. 적어도 AES-NI(하드웨어 가속 암호화)가 있는 경우에는 그렇지 않습니다. 이는 오늘날 매우 일반적입니다(최소한 랩톱 및 서버에서).
• restic은 암호화뿐만 아니라 데이터의 신뢰성과 서명에도 신경을 씁니다. 암호화 없이 이것을 구현하는 방법을 찾아야 하므로 어쨌든 키/암호를 유지해야 합니다.
• 암호화되지 않은 백업을 허용하는 코드 경로가 있으면 공격자가 클라이언트를 속여 암호화하지 않고 데이터를 (원래) 암호화된 저장소에 저장하도록 하는 방법을 찾을 가능성이 있습니다. 이전에 다른 백업 프로그램에서 그런 일이 발생했기 때문에 현재로서는 없는 시간과 리소스가 필요한 각별한 주의가 필요합니다.

내가 그들을 찾을 때 나는 더 많은 포인트를 추가할 수 있습니다.

암호화되지 않은 백업(로컬)을 원하는 또 다른 이유는 중앙 리포지토리를 여러 사용자가 공유할 수 있기 때문입니다. 개별 사용자와 논리적으로 분리된 것으로 표시되는 경우에도 마찬가지입니다.

공격자가 (원래) 암호화된 저장소에 암호화하지 않고 데이터를 저장하도록 클라이언트를 속이는 방법을 찾을 가능성이 있습니다.

흠, 리포지토리가 암호화되어 있든 없든, 암호화되지 않은 데이터를 암호화된 리포지토리에 저장하는 것은 불가능하다는 생각이 들었습니다... 그리고 암호화된 리포지토리가 어떻게든 동일한 파일로 암호화되지 않은 리포지토리로 대체된다면 이름과 위치를 입력하면 사용자는 암호를 묻지 않았음을 알 수 있습니다. 빨간색으로 깜박이는 굵은 텍스트의 경고가 인쇄될 수 있으며, 저장소가 암호화되지 않았습니다. :).

@wrouesnel 호스트 이름으로 구별하여 이미 할 수 있습니다! (요전날 저도 궁금했어요.)

@alexeymuranov 사용자가 입력한 비밀번호가 암호화된 디렉토리의 암호화 비밀번호인지, 암호화되지 않은 디렉토리의 진위 여부를 확인하기 위한 MAC 비밀번호인지 어떻게 확인합니까? 더 --switches ? 매우 빠르게 매우 지저분해집니다.

로컬 백업을 만들기 위해 이 옵션을 갖고 싶습니다. 예를 들어 매일 서버에서 ~/Music 디렉토리의 백업을 실행하지만 암호화할 필요는 없습니다. 백업은 하드웨어 오류나 손실로부터 보호하기 위한 것이 아니라(다른 백업이 있음) 사고 및 비트로트로부터 보호하기 위한 것입니다. 그리고 서버는 다소 저전력이므로 암호화 오버헤드가 문제입니다.

@alphapapa rsync 있습니다.
편집: 그리고 파일 권한/속성. BTW, "하드웨어 오류"와 "bitrot"의 차이점은 무엇입니까?

@cfcs , rsync 는 중복 제거하지 않습니다.

이를 위해 rsync가 있습니다.

@cfcs 우리 모두 알다시피 미러는 백업이 아닙니다. ;) Obnam을 사용하여 restic과 유사한 일련의 백업을 유지합니다. keep = 7d,8w,12m,3y GPG 키를 거의 잃어버릴 뻔한 이후로 반복적으로), 그리고 CD-R에 있는 몇 년 된 백업에서 그것을 파헤쳐야 했습니다. 저는 오래된 백업 데이터를 주변에 보관하는 것이 중요하다는 것을 알고 있습니다.

BTW, "하드웨어 오류"와 "bitrot"의 차이점은 무엇입니까?

Bitrot은 일반적으로 썩은 데이터가 필요할 때까지 감지되지 않고 전체 장치를 읽을 수 없게 만들지 않습니다. 하드웨어 오류는 예를 들어 디스크의 완전한 오류, 시스템의 부팅 실패 등입니다.

그리고 Alexey가 지적했듯이 rsync는 중복 제거를 하지 않으며 오래된 백업 데이터의 정리나 데이터 무결성 검사 등을 제공하지 않습니다. rsync는 훌륭한 도구이며 정기적으로 사용하지만 백업을 하지 않습니다.

암호화는 더 이상 비싸지 않습니다. 적어도 AES-NI(하드웨어 가속 암호화)가 있는 경우에는 그렇지 않습니다. 이는 오늘날 매우 일반적입니다(최소한 랩톱 및 서버에서).

소프트웨어가 go로 작성되지 않는 한. Go의 crypro는 인텔을 제외한 모든 것을 위한 소프트웨어입니다. 따라서 arm 장치를 사용하면 동일한 파일 세트에 대해 "예상 백업 시간 - 14일"이 붙어서 내 NAS의 공식 openssl 기반 백업 솔루션으로 30분 이내에 완료됩니다. .

저도 이 기능을 보고 싶습니다. 전송을 위해 SSH를 사용하고 LUKS/cryptsetup 암호화된 볼륨에 백업을 저장하고 있으므로 암호화하면 암호화 키를 잃을 위험이 추가됩니다. 또한 암호화는 오류 가능성을 높이고 CPU에 불필요한 부하를 추가합니다.

그럼에도 불구하고 암호화는 신뢰할 수 없는 대상에 백업할 때 매우 유용합니다.

사람들은 백업과 함께 암호가 포함된 텍스트 파일을 안전하게 보호하도록 동기를 부여할 수 있습니다.

나는 또한 luks/dm-crypt 암호화된 백업 대상을 사용합니다. /Backup/에 마운트하는 외부 USB 디스크
해당 위치(/Backup/restic_password)에 비밀번호 파일을 생성하고 --password-file을 사용하여 restic에 제공할 수 있습니다. 저장소는 /Backup/restic_repo/ 아래에 있습니다.
비밀번호 파일을 변경할 수 없도록 만드는 것이 중요합니다. 그렇지 않으면 실수로 잃어버리면 곤란합니다: chattr +i /Backup/restic_password
또한 만일의 경우를 대비하여 "restic"을 비밀번호로 사용합니다.

Restic의 암호화 기능은 클라우드 공급자와 같은 신뢰할 수 없는 대상에 백업하는 경우 매우 유용합니다. 그러나 집에 저장한 외장 드라이브나 지하실에 있는 NAS를 사용한다면 강제 암호화는 좀 미친 짓입니다. 일반 사용자는 어쨌든 암호를 잊어버릴 것입니다.

암호화되지 않은 백업을 허용하면 ZFS, BtrFS, NTFS 또는 모든 파일 시스템에서 백업을 압축할 수 있습니다.

(원하는 경우 하위 계층에서 dmcrypt를 통해 암호화를 수행할 수 있음)

암호화되지 않은 백업을 허용하면 ZFS, BtrFS, NTFS 또는 모든 파일 시스템에서 백업을 압축할 수 있습니다.

여기에서도 마찬가지로 압축 및 필수 암호화가 백업 서버에서 너무 많은 공간을 차지하지 않습니다. 내 사용 사례(일부 이미지, 많은 작은 xml/txt/csv 파일)는 암호화를 사용하지 않거나(ZFS가 작업을 수행할 수 있도록) 압축(zstd,5의 경우 ~2.3 압축 비율)에서 큰 이점을 얻을 수 있습니다.

ZFS를 사용하는 경우 zfs send 스냅샷을 사용하지 않는 이유는 무엇입니까?

ZFS 스냅샷은 많은 경우 백업에 충분하지 않습니다. 파일에 감지되지 않은 손상이 있거나 몇 년 동안의 저장 세트를 보유하려는 경우 ZFS 스냅샷은 그다지 도움이 되지 않습니다. 예를 들어 FreeNAS를 사용 중이고 1년 동안 매주 백업을 유지하려고 한다고 가정해 보겠습니다. FreeNAS에 내장된 일정 관리 및 스냅샷 관리는 이를 _정말_ 제대로 해내기에 충분하지 않습니다. "기업"이 아닙니다.

보다 정교한 스케줄링 시스템이 있다면 아마도 훨씬 더 잘 작동할 것입니다. 또한 zfs send에는 스냅샷이 있어야 배송할 수 있다는 문제가 있습니다. 또한 스냅샷 일정을 관리하고 RTO/RPO에 도달할 수 있도록 스냅샷과 전송 일정이 (수동으로) 동기화되었는지 확인해야 합니다.

그리고 예.. FreeNAS의 엔터프라이즈 기능을 말하는 것입니다. 하지만 그게 걱정...

적어도 AES-NI가 있는 경우에는 암호화 비용이 더 이상 비싸지 않습니다.

AES-NI 요구 사항은 많은 구형 서버를 제외합니다(어떤 경우에는 백업에 _특히 중요합니다!).

저는 누군가가 10년 이상 된 기증 하드웨어(일부는 여전히 32비트입니다!)에서 아프리카 시골의 서버 모음에서 실행되는 더 나은 백업을 얻도록 돕고 있습니다. 암호화가 너무 많은 오버헤드를 추가할까봐 두려워서 지금은 다른 곳을 찾아야 할 것 같습니다.

암호화하지 않은 경우 +1

이것은 유용할 것이다

암호화하지 않은 경우 +1

이것은 유용할 것이다

감시자의 받은편지함이 넘쳐나는 것을 방지하려면 '+1' 대신 원래 문제에 대한 추천 기능을 사용하세요. 감사합니다!

이 기능의 상태는 무엇입니까?

회사의 모든 사용자가 어쨌든 액세스할 수 있는 내부 삼바 서버에서 파일(사용자 설명서 번역과 같은 공유 문서)을 백업해야 합니다. 회사 범위 내에서는 실제로 기밀이 아닙니다. 이 경우 백업 암호화는 무의미합니다. 어쨌든 백업에 대한 추가 보안을 위해 탈옥을 사용하고 있으며 압축이 활성화된 btrfs 파일 시스템을 사용합니다. 어쨌든 다른 방법으로 VM 디스크 덤프와 같은 항목을 백업합니다. 내 사용 사례에서는 암호화가 문제가 아니며 데이터 손실을 방지하는 것이 유일한 우선 순위입니다. 'restic'과 같은 비밀번호를 사용하는 것은 어리석은 해결 방법입니다.

이를 시행하시기 바랍니다.

@mrkafk 암호화를 사용하는 데 있어 실제 문제는 무엇입니까? 필요하지 않더라도 CPU가 하드웨어 암호화를 지원할 가능성이 높기 때문에 문제가 되는 매우 구체적인 이유가 필요합니다.

내 실제 문제를 설명했습니다. 특정 컨텍스트에서는 필요하지 않지만 최소한 btrfs 파일 시스템에서 압축 이득을 제거한다는 것을 이해합니다. 백업할 파일이 너무 많아서 처음에 압축이 활성화된 btrfs를 사용하고 있습니다. hw 중복성을 위한 RAID-1을 사용하면 많은 디스크 공간이 필요하기 때문입니다. 내선4). 또한 가짜 비밀번호로 암호화하고 불필요하게 암호화하는 것은 어리석은 느낌입니다.

좋아, 당신이 쓴 것들 중에서 나는 한 가지 실제 문제를 모았습니다. 즉, BTRFS 압축이 암호화 없이는 효과적이지 않다는 것입니다. 그건 좋은 지적이야. 그 외에 나는 restic의 암호화로 인해 당신을 제한하는 것을 보지 못했습니다.

암호화되어 있지 않으면 암호화 키를 풀 수 없습니다. 이는 특히 백업과 관련이 있습니다.

메버스

암호화되어 있지 않으면 암호화 키를 풀 수 없습니다. 이는 특히 백업과 관련이 있습니다.

그것은 세상이 이미 내일 끝날 것처럼 논의되었습니다 :) https://github.com/restic/restic/issues/1786