Backup Strategy Advice
-
@girish said in Backup Strategy Advice:
As already suggested, for large data, it's best to use a hard disk / storage box. Just nfs or cigs mount it . S3 storage is not ideal for large backups, especially large file count. Ideally, choose a block storage which is in same data center.
In the future, we do plan to integrate something like restic or borg which will give us encrypted differential backups. I don't expect this in the next 3 months though.
https://forum.duplicati.com/t/big-comparison-borg-vs-restic-vs-arq-5-vs-duplicacy-vs-duplicati/9952
The above link could be useful for comparison between restic and borg.
But never trust, do your own tests.
ps: I dont know what duplicati is... I just found this comparison
-
@lucidfox I had same problem too with Wasabi, 26th of February. In January I switched to Wasabi to achieve better performances, reliability and stability (see below) and also for cheaper prices.
Last week I had the surprise: billed 30$ instead 5$ for 1TB because of their policy.
Yes, I had read their policy before, but you cannot know before how data upload and deletion will impact depending of Cloudron scheduled backups.
So I came back to old solution: Hetzner Storage Box and CIFS mounting.
Last January I switched to Wasabi because CIFS mounting had some unwanted unmouting problems. But now mounting points seems to be persistent and problem seems to be fixed.
About strategy, I suggest to purchase a Hetzner Box or a EX server (Eg. EX42) where you can install Cloudron+Minio.
-
I've had another thought on this, and something I'm thinking will work for our needs:
Hetzner and most others have daily snapshot backups, likely that those have the same resilience as any of their storage boxes, and using that has no CPU cost to your VPS, although in Hetzner's care a 20% extra cost on the VPS, which I feel has value in that there's no reliance on your own software to do this.
Which makes me think than any other off-site backups only need to be Weekly, for whatever retention period your needs require.
It doesn't solve the Wasabi 90-day charges for deleted data issue completely, or the Backblaze ingress costs, which aren't that bad after the first Rsync is complete - but it does reduce the data storage and cycling by a factor of 7, can be scheduled for weekends or days/nights when servers are least used, and still fulfils the provider and geo-replication aims.
-
^This also has additional cover in that when there's App or Cloudron Updates, the App or whole system has a backup triggered before those are installed.
Basically, daily off-site backups are probably over-kill for almost all of us that have VPS backup snapshots enabled too, and for anyone that doesn't, a provider storage box is probable going to be more efficient for daily backups and S3 should really be more for weeklies.
-
Thanks everyone for sharing your suggestions and insights (this is a very special community, and it's nice to be part of it). I've decided to try encrypted rsync to a Hetzner StorageBox via a CIFS mount. Others seem to be having trouble maintaining the mount with Hetzner Storage Boxes, so hopefully that doesn't happen too often. Even though there might be latency issues, I think this would be better than using a Netcup NFS mount, just so that the backups go to another provider from what the VPS is on.
@girish It would great if Cloudron could add more robust and nuanced backup options at some point. But I can understand that it's not priority at the moment (y'all are doing a great job with Cloudron).
@marcusquinn Your thinking on using the VPS snapshot does make a lot of sense. In my case most of the app data is on an Netcup NFS mount, so snapshoting the server wouldn't be very useful (I doubt the addon storage is included). So I've sort off flipped that on it's head, and will try doing daily rysnc backups (retained for a week) and then weekly automatic snapshots on the Hetzner Storage Box (you get a certain number free, depending on storage capacity). This doesn't have the effect of conserving VPS resources, but should extend the backup range without adding to storage costs.
-
@lucidfox Sounds like a solid strategy to me. Certainly right to have a multi-provider & encrypted setup.
One of the biggest risks I see with anything nowadays isn't technical but Ts & Cs and provider lock-out.
Their platforms, their rules, they can change at any time and you can be an accidental victim of bad actors in ways you'll never imagine before it happens.
From what I understand storage boxes have hardware redundancy, so I don't think that would be a point of failure - most backup recovery needs are user or software caused.
In my experience, no-one ever needs a backup past a week old, what is usually needed is the most recent recoverable.
So I think start with shorter intervals to get it all working confidently, then extend to longer intervals and don't store too old for the sake of it if you don't have some regulatory needs to.
This is my personal Cloudron setup now (rsync encrypted to Wasabi) + the 7 daily provider snapshots:
Happy with this for balancing costs, cruft and security.
-
@marcusquinn I don't have any regulatory needs. But it might make sense to reach back into the past, to a reasonable extent, in case a user accidentally deletes files and doesn't realise for a bit.
-
@lucidfox Haha, yeah, that happens - but some Apps have file-versioning or Trash features too, some allow users to flag a delete but the DB or file system doesn't delete until a sys admin purges. So you might be taking a sledgehammer to crack a nut.
If there's any apps in particular you think that might save you from backup exponentials and you're not sure, ping their names in here and I might or others might have a quicker answer.
Web Design https://www.evergreen.je
Development https://brandlight.org
Life https://marcusquinn.com -
@marcusquinn I suppose the other thought with rsync is that the retention period isn't so bad on storage space since its all incremental. Tarballs would be though.
So many variables to think through eh! So a worthy post and conversations to have evolve here for others I'm sure.
-
@subven said in Backup Strategy Advice:
Because of the encryption, you don't have to trust your backup provider.
Even though they are encrypted and you can technically put them anywhere doesn't mean just go with any provider (god forbid someone got a hold of your keys to decrypt). You should have reasonable beliefs that the provider you choose wont do anything with your backups (encrypted or otherwise)
I use DigitalOcean for my backups (Dedicated hosting with OVH/Kimsufi) DO is cheap and reliable and I know, even with my encrypted data, they wont try to do anything with it.
-
@marcusquinn Marcus do you have any workaround to manage Wasabi deletion policy? I mean, now maximum Cloudron retention policy is "1 month" or "forever".
So in case 1) you are under 3 month Wasabi policy. In second case 2) you should remember each month to delete backups older than 3 months.
@girish Can be interesting to add a "3 month" or "4 month" option?
-
@p44 My current workaround since figuring the 90-day ruse out is to make a new account and let the old one go
I'm still looking at options but might just made the backup interval longer for now and avoid tarballs.
Agreed, the interval and retention options could have a few more to cover things like this.
-
@marcusquinn LOL!
But I think it takes time, specially if you've to configure each time sub-accounts... -
so just to update my results here - i tried a hetzner storagebox, but the cifs storage mount was having some stability issues. and it was so painfully slow as to be practically unusable.
so i switched to another option that i've seen mentioned in the forums here, which is to backup to a second cloudron using minio. and i'm happy to report that it's working fine. using an alphavps storage vps it's actually even cheaper, and it's quite convenient to have a further backup if needed.
-
@p44 sometimes in cloudron it would say 'this is not a cifs mount' or something similiar. even though it seemed to have been mounted properly, and showed up when checking via ssh. it could just be something to do with mounting it incorrectly though. i figured it was not worth troubleshooting, because of the slow speeds.
