I have gone through different topics but nothing answered my specific question.
Uptime, backup and securing the Nextcloud instance. I am looking at ways how I can guarantee uptime of 99.9% and a backup plan when something would go wrong with my data.
How can I best secure this?
I have looked into Docker Swarm and Kubernetes for example to set up nodes/instances to which would be duplicate servers running of the same Nextcloud instance.
Is this possible or what complication could I run in to?
Has anyone tried setting it up security matters like this to safeguard your data instead of using backups?
To your question, part of it depends on what hardware you have available. For example, if you have a VMware ESXi cluster, you can have redundancy at the hardware level and may not need redundancy in Docker.
Thanks for your reply KarlF12! And yes, I do agree, there is not such thing as NOT using backups. Uptime and having access to files at all time is the goal here. I am planning to make backups additionally to running the nodes/kubernetes or a solution to be able to make this possible.
I haven’t looked into the ESXi cluster yet, there seems to be quite some options out there. However, I’m wondering if anyone out there has actually set up a trustworthy architecture and would share their experience towards the uptime goal
Haha, yeah that’s a nice lean-startup business model, however I need this for securing data of a client. Users at the moment is around 25, data is expected to grow to 50Gb, and as a cloud service.
Budget will be between 50-100 Euro / month
restic backup it’s already integrated into my playbook:
well. someone has to write a restore script. in case of a total server loss. if you have to restore a file deleted by a user that would be manually restored.
so. the playbook - together with some cloud-init magic and a yet to be written restore script - would give you a quick “bare-metal-restore”. 10-20min you would be up again.
if you consider aws as your cloud provider and you want to have a restore automated in case of failure: put your data, database and nextcloud app on an efs share. (might be a performance killer for the database. depends on the files access frequency.) run the ec2 server in an autostart group. you have to create a “nextcloud ready” ami. that is to say a boot image that has nginx, redis and postgres installed and would mount the efs share at launch time. the aws autoscaling mechanism would kill and recreate the ec2 in case port 443 is longer answering. and will send you an email if that happened.
that is similar to the idea of container. you put your data on a reliable, persistent storage (efs) and your app on immutable hardware (ec2). if anything happens to nextcloud (or the server) it will be recreated automatically.
nextlevel: you use rds (aws database service) for the postgresdb and elasticache (for redis). on the ec2 you would have only nginx and nextcloud app.
(not sure because I didn’t test it yet. in this scenario you could add as well a load balancer and more than one ec2. but that wouldn’t be in your budget anymore.)
since you considered docker and kubernetes: docker wouldn’t do the trick. if the server fails, docker is dead also. kubernetes is - imho - far too much for your purpose. it would only make sense of you have more than one client.
