Here's a strategy I use, although I wasn't thinking of ransomware at the time.
I have a script which first does a 'tarsnap --dry-run', and parses the summary output from that. It checks the 'Total Size' and 'Compressed Size' of the new data, and will skip making a real-backup if that size seems unreasonable. Think about this for a second: If you are hit by ransomware, then you probably don't want to upload *any* of that encrypted data to tarsnap's servers. If the update-size seems reasonable, then I go ahead and create a real update. Note that I also break up my backup into multiple separate tarsnap archives. So, for instance, it might be reasonable for my "Documents" backup to have a lot of new data in it, but it would be extremely suspicious if the backup of all my svn repositories had a huge amount of new data. What I have is even more convoluted than what I've described, and I'm pretty sure that my scripts wouldn't be useful for others. But that's the direction I would consider if I were you. -- Garance Alistair Drosehn = gadc...@earthlink.net Senior Systems Programmer or g...@freebsd.org > On Jul 12, 2017, at 9:36 AM, Rob Hoelz <r...@hoelz.ro> wrote: > > Hello fellow tarsnap users! > > I just started using tarsnap, and I was wondering if there exists an > option (or the potential interest in developing an option) to put a cap > on an archive size. The reason I ask is on the off chance another > tarsnap user or I gets bitten by ransomware and it encrypts their /home > directory, I would expect the archive size for an automated backup to > really balloon in size (seeing as it's kind of hard to deduplicate and > compress random data!), and it would be nice to avoid burning through > one's account balance to add insult to injury. Not that I intend on > getting bitten by ransomware, but you never know! > > The closest thing I could find is the --maxbw option; is there a > corresponding option for archive size that I'm not seeing on the > manpage? > > Thanks, > Rob