Koen Verbeeck (with inspiration from Alexander Arvidsson) asks about the scenario of returning to on-prem from the cloud. Koen wonders if it’s a European concern, and being in Australia, I’m not entirely sure. I have clients in three of the four camps – ones who are in the cloud and staying there, ones who are on-prem and staying there, and ones who are in the process of moving from on-prem to the cloud. None are moving from the cloud back to on-prem, but I’m sure some of the reasons that kept the on-prem clients from moving could easily spread to those who are in the cloud. The European concerns could easily become similar in Australia – we have sovereignty concerns that are similar to various European nations – and I’m a little surprised that they aren’t already.
One of the things that Koen asks about is training people new to on-prem – things they wouldn’t necessarily know if they have only worked in the cloud. My mind turns to disk-related issues such as restoring from log files, and to corruption. There was a while when database corruption seemed to be quite commonplace – or at least a reason for people to get in touch with me to help. It’s definitely a lot less of an issue nowadays, even for on-prem environments, but the underlying concepts of disaster recovery are definitely something I think should be understood by SQL professionals.
I feel like every SQL professional should be able to argue their reasons for choosing a particular frequency of log backups, where those backups are going to, and what happens to those files. Is recovery tested regularly, including to a specified point-in-time? And can the data professionals explain what’s needed for that? Do they understand tail-log backups, and how to take one if the LDF file is all that can be salvaged (and do they even understand the importance of salvaging the LDF file)?
I like to think that junior DBAs are trained in this even if they never use on-prem environments. But I’ve definitely come across gaps.
Reliance on data is more and more significant for all organisations, but more and more of that data is in SaaS systems, where the data is stored on the servers of those separate systems. We don’t think about how this data is stored in these online systems, let alone how to back it up and what those companies do to make sure they can recover our data in case of disaster. We might extract the data for analysis, but if these systems become on-prem once more, running on local databases with local DBAs, understanding how to recover will be critical.
I do wonder how many organisations would cope if they had to pull systems back from online systems. I have clients who only use systems that can guarantee the data stays in Australia, but this doesn’t tend to include “controlled by Australian organisations”. Considering news articles in 2025 (such as at https://www.forbes.com/sites/emmawoollacott/2025/07/22/microsoft-cant-keep-eu-data-safe-from-us-authorities/) reported that Microsoft could be forced to “snoop” on EU-hosted data – although they would push back on any such requests (https://broadbandbreakfast.com/microsoft-pledges-to-protect-european-operations-and-unveils-data-center-expansion/) – I wonder whether those concerns should be raised even higher. Is anyone asking the smaller SaaS companies what they would do if the US government asked them for sensitive information held in non-US data centres?
One thing is for certain – if tension increases between your country and the country of the organisation that has your data, then you will have an interesting time ahead.
@robfarley.com@bluesky (previously @rob_farley@twitter)
