I too tried moving to DigitalOcean because their offering seemed very compelling. Turned out to be a huge mistake.
After waiting some weeks for Arch to be re-released I finally booted an Arch image. Not a week had passed and some kernel upgrade had already made the system unavailable (no network on vm). I forced nothing, just ran sudo pacman -Syu as I always did on Linode.
Support didn't care. For days I tried responding to the ticket that I opened, talking to them on the irc, via mail. Nothing. I tried to request help to at least recover the files. Nope, nothing they can do.
I did not understand the true value of good support. Now I do. Back to Linode.
For two reasons: First they created a "supported" image that had no IgnorePkg = linux as it should since they don't support upgrading the kernel. They did this on their Ubuntu image. They failed to it with the Arch image. Second, you have no access to the kernel that is used to boot the system. Even after upgrading system kept booting the old kernel but network was still down. Nothing a user can do at this point.
You can access a recovery image on linode I'm guessing there is no such thing available for Digital Ocean is why he was asking for help in recovering files (even prgmr offers a recover images that you can use to recover files).
The fact that he didn't get any help is a problem that is what support is supposed to do and if he expects a higher level of support than Digital Ocean provides and Linode provides that I see no problem.
Hmm, I still don't follow you. Does Linode have this? After moving I haven't found any difference in features. Perhaps I just wasn't using this on Linode? What does it let you do that restoring from a backup can't?
(The use case in this thread is backups as voidlogic mentioned.)
The use case I gave was looking up logs to see how something failed and to access files that aren't backed up but still exist on the virtual drive (this can happen when the OS fails to boot). You can also repair the virtual install if you accidentally messed up a configuration file or something like that.
How is this Arch's fault? The user did the same thing he/she normally does on Linode. This is a case where the Linode ops really understand Arch and everything just works (the 'linux' package isn't installed on the image) but the provide the latest kernels. On DO I also originally ran into this issue but support never gave a clear reason as to why, from digging around it appears to be with the 8139cp/too kernel modules (they don't load). It seems like some kind of version issue but I haven't had the time to play around with this more.