Duplicity: एन्क्रिप्टेड bandwidth-efficient backup

मूल लेख ↗ Hacker News चर्चा ↗

Duplicity के encrypted, bandwidth-efficient backups पर मिश्रित प्रतिक्रियाएँ मिलती हैं: कुछ लोग इसकी लंबे समय की reliability और GPG integration की प्रशंसा करते हैं, जबकि अन्य तेज़, पूरी तरह deduplicated, content-addressed snapshots के लिए Borg, Restic, Kopia, और Duplicacy जैसे नए tools पर चले गए हैं। टिप्पणीकार versioning, deduplication, encryption, और cloud storage (जैसे S3, B2, Glacier) के दृष्टिकोणों की तुलना करते हैं, simple mirroring scripts और purpose-built backup systems के बीच trade-offs, तथा restores का परीक्षण करने और repository corruption या performance issues को संभालने के महत्व पर ज़ोर देते हैं.

Duplicity के बारे में समग्र धारणाएँ

  • इसे एक मजबूत, लंबे समय से उपयोग में आने वाला, एन्क्रिप्टेड बैकअप टूल माना जाता है; कुछ लोगों ने इसे कई वर्षों तक बिना किसी समस्या के उपयोग किया है।
  • मुख्य तकनीकी आलोचना: full + incremental मॉडल के कारण लंबी बैकअप शृंखलाएँ बनती हैं, स्टोरेज अधिक लगता है, और समय-समय पर नए full backups की आवश्यकता होती है।
  • कुछ लोगों को यह CPU-heavy लगता है (जैसे macOS fans का तेज़ घूमना) और नए विकल्पों की तुलना में कम efficient।
  • cron output में noisy Python warnings की शिकायतें; यह भी उल्लेख किया गया कि पुराने installs अभी भी Python 2 पर हो सकते हैं।
  • बताई गई समस्या: जब एक backend fail हो जाता है (जैसे SFTP IPv6 routing problem), तो Duplicity “continue on error” settings के बावजूद पूरी तरह abort कर सकता है।
  • restore semantics पर सावधानी: target directory को गलत तरीके से specify करने पर वह restore करने के बजाय overwrite हो सकती है।
  • उल्लेखित frontends: Duply और DejaDup (experimental Restic backend के साथ)।

अन्य backup tools के साथ तुलना

  • कई टिप्पणीकार Duplicity से Borg, Restic, Kopia, या Duplicacy पर चले गए हैं।
  • Borg: deduplication, तेज़ frequent snapshots, आसान restores के लिए FUSE mounting, pruning policies, और छोटे repos के लिए प्रशंसा; आलोचना में एक ही repo को एक साथ multiple hosts द्वारा उपयोग करने में कठिनाई शामिल है।
  • Restic: single-binary simplicity, FUSE mounts, “dumb” remote backends (S3, SFTP) के समर्थन, और encrypted data की dedup+compression के लिए सराहना। कुछ लोग अधिक memory use, performance issues, और second-level timestamp granularity जैसी quirks की रिपोर्ट करते हैं।
  • Kopia: content-addressed, deduplicating, zstd compression और complex ignore rules को support करता है; कुछ शुरुआती चिंताएँ repo size के “ballooning” को लेकर थीं, लेकिन अन्य लोग Borg के बराबर प्रदर्शन की रिपोर्ट करते हैं।
  • Duplicacy: multi-machine, single-repo setups के लिए reliable माना गया, cloud में आसान replication के साथ।
  • Duplicati: मध्यम आकार के repos पर भी बेहद धीमे या प्रभावी रूप से विफल restores की कई रिपोर्टें।

Cloud storage और S3 strategies

  • सरल aws s3 sync shell scripts को एक alternative के रूप में प्रस्तावित किया गया, लेकिन अन्य लोग नोट करते हैं:
    • वे structured backup history को बनाए रखने के बजाय mirror करते हैं, जब तक कि S3 versioning का उपयोग न किया जाए।
    • block-level differentials या deduplication नहीं; बड़े files के renames/moves महंगे होते हैं।
    • server-side encryption end-to-end नहीं है; Borg/Restic/duplicity द्वारा दिए गए client-side encryption और dedup को अधिक मजबूत माना जाता है।

Content-addressed और deduplicating designs

  • content-based IDs और rolling hashes (जैसे Kopia, Borg, Restic में) सक्षम करते हैं:
    • cross-host deduplication।
    • periodic full backups के बिना “full” logical snapshots, क्योंकि blobs साझा होते हैं और garbage-collected होते हैं।
  • उठाई गई चिंताएँ:
    • blob sharing का अर्थ है कि corruption उन सभी snapshots को प्रभावित करती है जो उस blob को reference करते हैं; mitigation के लिए redundancy (RAID, erasure coding) और periodic verification सुझाए गए।
    • ऐसे designs metadata और file similarity की कुछ जानकारी leak कर सकते हैं, इसलिए अत्यधिक paranoid users simple tar/zip + whole-archive encryption को prefer कर सकते हैं।

Usability, GUIs, और orchestration

  • Borg के पास mature GUIs और orchestrators हैं (जैसे Vorta, Pika Backup, borgmatic)।
  • Restic का ecosystem अधिक fragmented है: कई wrappers (autorestic, resticprofile, Backrest, npbackup, Prestic) मौजूद हैं जिनकी maturity अलग-अलग है, जिससे चुनाव कठिन हो जाता है, खासकर non-technical users और macOS support के लिए।

Data integrity और backup testing

  • नियमित रूप से backups का परीक्षण करने पर ज़ोर, केवल उन्हें बनाते रहने पर नहीं।
  • Borg के लिए, borg check --verify-data को cron via चलाने का सुझाव, साथ ही कभी-कभी manual restores (जैसे VM में) करके end-to-end recovery की पुष्टि।
  • कुछ tools repository checking और random subset verification प्रदान करते हैं; corruption detection के साथ redundancy और offsite copies को best practice माना जाता है।

अन्य warnings और recommendations

  • rdiff-backup के उपयोग के विरुद्ध स्पष्ट चेतावनी, क्योंकि ENOSPC handling, जटिल “regress” operations, और कई reverse differentials के साथ inefficient restores से संबंधित समस्याएँ रिपोर्ट की गई हैं।
  • कई टिप्पणीकार restic + rclone, या Kopia की सिफारिश करते हैं, जिन्हें आधुनिक, stable, encrypted, deduplicating solutions माना जाता है जो cloud backends और बड़े data sets के साथ अच्छी तरह काम करते हैं।