Linode in particular uses a custom agent in the host OS to back up at a file level. (Linode does some crazy iSCSI stuff that most of us mere mortals will never mess with.)
A more widely-used solution is LVM's "snapshot" target (sample write-up here) which is more or less good at hot backups. Basically, if you're using Logical Volume Management, you can tell the system to make a copy of one of your volumes (say, the one mounted as /var) to a currently-unused volume. (YMMV; caveat emptor; void where prohibited -- in particular you'll have the usual snapshotting problem if there's rapidly changing data)
In fact, because of that problem, databases in particular are usually backed up through some kind of log shipping rather than snapshots at a given moment (I don't know MySQL/MariaDB that well, but I DBA both Postgres and Oracle sites and that's how we always do it). Basically your servers keep track of all their transactions, and pretty steadily report those to a non-public backup server, which records them (think "replication but with a lot more tolerance for latency"). This way you have more control over how far you need to roll the database back than if you just, say, take a nightly snapshot (though DBAs are paranoid enough that we often do that too).
Personally, for my development machine at home, my solution is just to use a good version control system (I like git) for all of the directories I care about and once in a blue moon tar them off to the cloud or an external hard drive or something; since I rarely actually blow up the system itself (I more often do something stupid with my own files) it's all I've ever needed on a local machine.