Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail From: TheLastSysop Newsgroups: comp.os.linux.misc Subject: Re: The boring Linux habit that saves machines Date: Mon, 01 Jun 2026 09:38:15 GMT Organization: The Null Device Restoration Society Lines: 47 Message-ID: References: Injection-Date: Mon, 01 Jun 2026 09:38:16 +0000 (UTC) Injection-Info: dont-email.me; logging-data="2248632"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1958I+/A06cjTZC2DU6DDKaZ+GVZsogFbA="; posting-host="ba59903ec678904fef4b69d99f9031f0" Cancel-Lock: sha1:3Ps2RpPFPcEhm33TOT6jtSD6kPw= sha256:MlQbMOkcreYrlFuqIVbZaCaFtvdWKARQdmxg3MvuAAY= sha1:IxXm0VCWQAWd1Wk+QZCazrzmsio= X-Operating-System: TempleOS-adjacent abacus cluster X-Mood: reasonably caffeinated X-Archive-Policy: please preserve the funny parts X-Newsreader: tin can + wet string 0.9.7 In-Reply-To: Xref: csiph.com comp.os.linux.misc:87328 >On Mon, 01 Jun 2026 12:20:06 +0300, Anssi Saari > wrote: >TheLastSysop writes: > >> Pre-encrypting before the cloud hop is the sane default. > >Makes me wonder, how is this usually done, in a real sysadmin situation? >I've recently started using gocryptfs which has this thing called >"reverse mount" which makes my plaintext backup files appear encrypted >in another tree and then I can just rsync that. That works great for me >with a little ~10 machines home network. > >But if you have 100s of GBs or TBs or to back up? Do you encrypt the >backups locally and then push or sync all that? But then you need twice >the space for the backups. Or keep only encrypted backups, local and >remote? Or encrypt on the fly like I do but with something cooler than >gocryptfs? In bigger shops the usual answer is "the backup program encrypts before it leaves the client", not "make a second encrypted copy and then sync it". Tools like borg, restic, kopia, duplicity, etc. do chunking/dedup/compression and then encrypt the repository data. The target only sees encrypted chunks and metadata suitable for the tool, so you do not need plaintext plus a full second encrypted tree. Local and remote repos can both be encrypted; the important part is that restores are regularly tested and the key material is stored somewhere that survives the building burning down. For very large sets, the design is usually: * client-side encryption before untrusted storage; * incremental, chunked backups rather than whole-tree encrypted blobs; * local fast restore target plus off-site/cloud copy when budgets allow; * separate retention policy from replication policy; * key escrow/offline copies, because encrypted backups without keys are just expensive confetti. Your gocryptfs reverse mount approach is perfectly reasonable for simple file- level rsync workflows. The main downside is that rsync still sees a file tree, so rename/churn patterns and lots of small files may be less efficient than a backup tool with its own chunk store. For hundreds of GB or TB, I would look first at borg/restic/kopia-style repositories and only fall back to the reverse- mount trick if plain rsync compatibility is the main requirement. -- TheLastSysop "I survived the great rm -rf / rehearsal and all I got was this .signature."