5 ms·

Reminds me: I have to give tarsnap a shot

• msbarnett 11y ago
  It's 100% excellent. Highly, highly recommended.
  • tdurden 11y ago
    Technically, I agree...however, you are trusting your backups to a one man operation.
    • cperciva 11y ago
      Not a one-man operation any more! Admittedly still a bus-factor-one operation though, since man #2 doesn't know how to keep everything running yet.
      • tdurden 11y ago
        Great to hear!
      • bmir-alum-007 11y ago
        Having done this a few dozen times: A best practice is to ask the next new person to keep notes of obvious questions/unclear details to put in an internal, secure wiki. The issue, as founders, we often don't think about what is obvious to us when we deployed an app and all the server tweaks necessary to get it going, for teaching someone else or replicating what was done. Then, they learn some things and put them into the wiki. Rinse-later-repeat until there's few/no questions as the team grows. It's continual DR/BCP housekeeping: architecture diagrams, instance inventory/config and other critical info (contact / escalation info) updated so that it's run-over-by-a-bus and EC2-burns-down (almost) resilient. As you scale, having someone put server config all in Chef or Puppet (cfg management stored in git) will also help reduce deployment pain at the expense of initial setup pain. Initially, a wiki page containing a giant shell script for each server box kind is usually a faster hack.
    • bmir-alum-007 11y ago
      Just use multiple services for HA, which is a SPOF of selecting any one service regardless, not specific to Tarsnap. Also, check out Tahoe LAFS. Nonproblem strawman solved. :)
      • tdurden 11y ago
        that's not the point
        • bmir-alum-007 11y ago
          What's the point? Tarsnap is modestly cheap and extremely secure, and there other backup services which are equally cheap and almost as secure. Use at least 2x services always, so Tarsnap going down or bust (heaven forbid) isn't a big deal. There is never a perfect real-world solution, but risk mitigations that reduce risk at a higher levels of abstraction is how to get real, production-grade fault-tolerance the easier way than dredging up edge-case issues without offering usable alternatives. SpiderOak uses end-to-end encryption, but I wouldn't trust it completely https://spideroak.com/opendownload https://spideroak.com/opendownload rsync.net is also pretty usable, but I wouldn't trust there is any in-flight or at-rest security http://www.rsync.net/ http://www.rsync.net/ Tahoe LAFS provider https://leastauthority.com/ https://leastauthority.com/ (it's possible to run your own Tahoe LAFS servers on cloud/colo boxes on several providers) The best-practice mitigation to allow backups on less secure providers is encrypt locally (end-to-end encryption effectively) and distribute restore keys to a decent quorum of managers/founders/supervisors. Having done offsite LTO tape vaulting and formal disaster recovery / business continuity planning at the organization level, it's a whole lot cheaper, easier and more flexible to use multiple cloud providers for most real use-cases (apart from multiple PiB datasets).
          • tdurden 11y ago
            The point was that trusting all your backups to a one-man operation is not particularly wise, though cperciva provided more information. HA and using multiple services was not part of the conversation.
• feld 11y ago
  install sysutils/acts to make it dead simple Just start with this and you'll have backups in less than 5 mins http://blog.feld.me/posts/2015/05/braindead-freebsd-backups-with-tarsnap-and-acts/ http://blog.feld.me/posts/2015/05/braindead-freebsd-backups-...
  • bmir-alum-007 11y ago
    Nice! For larger sites, having a NAS/SAN setup with enough cheapo spinning-rust is a good way to consolidate onsite->offsite backups (using multiple providers). 0. Use backup agents for local boxes to make a compressed, encrypted backup to the NAS/SAN on some host-unique temporary dir on the same volume as the offsite dir. 1. Test restores of backups to throwaway VMs before blessing them as good for offsite storage. Fail any backups that fail this test. (Very important for checking backup jobs and restore automation processes. An untested backup == not a backup.) 2. Use mv to move the compressed backup from host-unique dir into the offsite dir. 3. Continuously replicate the offsite dir to offsite providers. 4. Prune old jobs as needed, which then replicates. (Be sure to set provider-specific previous backup retentions appropriately, to avoid error replication issues.) 5. Sleep at night.
  • Khaine 11y ago
    Thanks for the great advice :)