DigitalOcean does provide a backup service, which must be enabled at the time of deployment (it’s not something that can be enabled after the fact). That said, the backup service does not offer the ability to customize and the backup times are not guaranteed. This means that while one backup of your Droplet may run at, for example, 6 AM EST/GMT-5, the next backup may run sooner or later.
If the plan is to deploy a true production server, your best bet is to offload backups to another service, such as Google Cloud Storage or Amazon S3 that way you’re able to control frequency, rotation etc.
As for DDoS protection, it’s not something that is currently offered in the form of a service, though it is something you can somewhat configure and manage on your own through a cluster setup to create a high-availability environment.
Quite a few people use NGINX as a proxy, many others use HA Proxy, some also use Varnish as it’s not just for web acceleration – it can be used as a caching reverse proxy.
An minimal (read: basic) setup for a database driven website might look something like:
- 2x Droplets - Varnish Cache (RAM: 2-8GB’s / ea)
- 2x Droplets - NGINX (RAM: 2-4GB’s / ea)
- 2x Droplets - MariaDB (RAM: 4-8GB’s / ea) - Master/Slave
- 2x Droplets - Redis (RAM: 1-4GB’s / ea)
In this case, Varnish is the first point of contact and it decides which of the two NGINX servers receives the incoming request. The NGINX servers would be setup to sync with one another. The MariaDB servers would be setup in a Master/Slave configuration and the Redis servers would receive connections from both the NGINX & MariaDB servers only (short of being able to communicate with each other).
Again, this is a very basic setup, though it provides separation of services (short of PHP-FPM being run on the NGINX servers, which could be further separated to their own Droplets the need truly arose) and some added reliability.
Will it stop, prevent or mitigate a DDoS attack? No. Unless you go with a dedicated service that handles such large-scale attacks, it won’t really matter who you’re hosting with. Most large shared hosting, VPS and even dedicated server provides are not even capable (read: willing to accept the beating in exchange for sacrificed service reliability) of handling large-scale attacks for their clients, short of null-routing (as that’s often the first solution), unless the client is paying for such a service specifically. In most cases, this would be something you’d want to communicate upfront to any provider, especially if you’ve been a target in the past.