All I can say for certain is that he will not reply if you do not email him. Just keep it professional and state only the facts, is the only thing I can offer.
unfortunately not, i dont have access to the storage at all, also backups wouldn't be a good idea (storage size is 800gb, we have a 100k+ user website where users frequently upload files)
If your business depends on it, not backing it up in some other place on a consistent basis is a bad idea. The cost of this should be factored into the price you charge people. 800GB would be less than 20 dollars on S3, all you have to figure out is the replication process, but that shouldn't be rocket science either.
It's a hard lesson to learn like this, but it's a learning moment nonetheless. You don't rely on your provider to make backups for business-critical stuff like this, you need to manage it (and test!) it yourself.
rclone[1] supports tons of storage providers. If you get access back and recover your business, start making backups onto other providers.
I would say the lesson is just use AWS which has outstanding support. Building backups yourself, going multi cloud or else just erase the benefit of CF. If you do this you can just run on a bare metal and save on cloud cost.
external/independant backups are a thing. They would be part of a disaster recovery plan (and you should test the restore process and result from time to time, else they might be worthless when you actually need them).
I understand this is not helpful right now, but there are best practices and many ways to plan for this kind of stuff for good reasons. Some things can and will go wrong, and sometimes that may cost your business a lot, which means you have to anticipate (or accept) the possible costs and risks.
This is very unhelpful. There's a difference between "someone fatfingered a command and brought this mysql machine down" and "our cloud provider shut down a core feature for our account".
When you design a new system do you plan for S3 to go down for more than a day? Do you have a fleet of offsite machines to smoothly transition to? If not, why not?
Well, it is about things to prepare before being in this situation, I acknowledged already that it was unhelpful now, since it is too late. It is advice for other business deciders looking at this, or for this one for changes to implement in the future.
Sometimes the plan is "well, this business had a good run, now it is over".
Sometimes it can be as cheap as "well, here's the documentation to run all my stuff elsewhere, starting from my external backups"
Depends on how much money you lose from a failure and how likely the failure is. As an additional point, you may not plan for s3 going down, but even a price hike on egress traffic may put a business in trouble if trying to move without already having external backups. So, as often, you have to do some cost/risk analysis. But having backups not controlled by your main provider is often considered a good idea.
Technical problems, human error, cost changes, various disagreements between provider and customer, can all be made easier if you have a plan B rather than being stuck with a single provider or solution
If data on S3 is crucial for business to be alive? Of course! I would even think about writing data to 2 separate storages in real time to be able to switch easily.
3-2-1 backup is a no joke, especially when it's your business, not a hobby project. Having DR too. And it's not a legacy, 20 years old system, so it's much easier to do such plans and test them.
You don't have to run it a entire duplicate of your current infrastructure, just plan for it to happen (depending on impact to your business). Then it means you can think about doing it after a few days of downtime, maybe earlier depending on difficulty/impact.
But, yes, you do have to plan to run it elsewhere and consider wether various features may make it harder for you to move on. vendor lock-in is a known business risk
Running multicloud (at the same time) is for availability not disaster recovery. Just having another copy of the data outside is good for DR, even if you have to redeploy everything manually in a hurry.
"There's a difference between "someone fatfingered a command and brought this mysql machine down" and "our cloud provider shut down a core feature for our account"."
No there isn't. Those are both exactly the same problem with exactly the same solutions.
