We were not able to find any issues here. Perhaps it was temporary or there was confusion about the setting or what site it was referring to. Please reply and let us know if this is still an issue for you or it happens again.

Very sorry for the downtime you experienced. This is the report we received from our cloud provider: Start: 2019-05-13 12:30 UTC Hello, We have identified an issue on the physical machine hosting one or more of your Droplets, which are listed below. In order to minimize disruption, we will be attempting a migration of the Droplets to a healthier physical machine. Throughout the migration, control panel and API events will not succeed for the affected Droplet(s) including power offs, resizes, and attempts to destroy the Droplet. In order to minimize downtime, we will first attempt to perform live migrations in all possible cases. A live migration would result in no downtime, but minor performance decreases in disk I/O and a second or less of packet loss as the network is switched over to the new physical host. In the event that we are not able to perform a live migration of a Droplet, we will perform an offline migration during which the Droplet will be powered off and migrated offline during the window. We apologize for any inconvenience, and will be happy to answer any questions or concerns- simply reply to this email, or open up a ticket on your account. Affected Droplets: eduvlogs.wpmudev.host These kind of issues do happen to one or two out of our thousands of hosted sites each week. In only 2 or 3 cases in the last 6 months was a sever unable to boot after recovery like happened to your site. We have tasks that we are working on to forward these kind of messages to customers, as well as build new monitoring processes that can detect this specific kind of issue for our SysAdmin team to manually respond to in case it happens again.

They won’t always add up. The total will always be perfectly accurate as that’s is total zpool usage. The individual values and graphs are just to give our best approximation of how big each type is relative to the other in how much space it uses. Due to the nature of ZFS filesystem you can’t perfectly separate storage used by snapshots and clones from their parent filesystem. That backup overhead should rotate out on its own soon though, it’s rare to see that much except right after deleting a lot of data. This may help if you can wrap your head around it: https://blogs.oracle.com/solaris/understanding-the-space-used-by-zfs-v2

Thanks for the suggestion. Unfortunately DO does not provide any api to access their monitoring stats, they are only available in their control panel. We do have an advanced live stats screen on each server that support staff can give the link to on request (ask for Netdata link), but to save RAM usage we only store 6 hours of history with that, it’s not designed for historical stats.

Hi there, thanks for the feedback. I understand it's hard to wrap your head around. The amount are accurate, but hard to understand because it's using a ZFS filesystem. That means different parts are incremental of other parts as they are based on clones or snapshots, and a lot of other strange things that's hard to understand without some really in depth technical documentation. And yes the DB space is the filesystems that mysql actually uses. It can have a lot of overhead per mysql instance as InnoDB preallocates space for its log files, data, indexes, etc. So even with no DB the overhead runs about 650MB. All I can really tell you is that those graphs are meant to simply answer the question that many user's kept asking, which is "what is using up my storage space?". And this should help a little bit.