I was using Duplicity when I experienced the bad encrypted backup. I blamed it on CBC. But the real lesson is to verify backups and test a restore, well before you need those backups in a real disaster recovery situation. And I'm in theoretical agreement, backups *should* be encrypted *and* stored securely.
Had a bad experience once where a bad block on an encrypted backup invalidated the entire backup. Now I'm a big proponent of UNencrypted backups stored in a physically secured area.
@bobjonkman @wakarimasen Yeah, periodic verification is key. And having both offsite and onsite backups is also vital. My onsite backups are on drives with luks/dm-crypt'd full-disk encryption, I consider that safe enough. I use Duplicity for the "backups of the backups" that are going offsite.
I used to use owncloud's encrypted storage, until I looked deeper into it and realized how PANTS ON HEAD RETARDED it is. The encryption may be fine (I have no idea, I'm no cryptographer) but they don't obfuscate filenames.
"La dee da, I'm a bad guy who's got a folder full of encrypted files from someone's owncloud install, let's see, there's a little file called passwords.txt, gee, I wonder what file I'm gonna aim my password cracker at first?"
@wakarimasen @bobjonkman Way ahead of you. :) Every encrypted drive I have has a backup of the headers and keyfiles for all the other encrypted drives.
!ownCloud and !Nextcloud need access to the encryption key, but the offsite storage provider does not. So, if you keep your ownClould/Nextcloud server securely on your premises then you can use an offsite storage provider and get some additional security from encrypted storage.