all-inkl.com - Stable pricing since 2017

14 years with the same host is actually a better seal of quality than any advertising claim :) If during that time neither price nor support nor technology have been annoying enough to make you move, they must be doing a lot right.

Regarding the commission, I would always check whether it only applies to the first order and what happens in case of withdrawal/termination — six weeks sounds like the usual waiting period for that. Do you still remember which plan you took back then and whether its scope of services has changed over the years?

That sounds like the best compliment for a host: everything has been running for 14 years, the price remains fair, and if something does go wrong, support is there. Especially bundling several projects into one package makes the unchanged price even more pleasant.

It would only be interesting to know whether they now also keep up so effortlessly with things like PHP versions, backups, and IPv6. But 'you hardly notice the host' is truly worth its weight in gold on this topic.

It’s really when you have several projects that you find out whether a package holds up in the long term. Not just because of storage and domains, but also when it comes to the less visible things: up-to-date PHP versions, database updates, SSL certificates, and a workable backup strategy. If all of that scales without constant add-ons or tinkering, a price that has stayed the same for years is actually pretty impressive.

That said, I would never rely *only* on the host for backups—no matter how reliable the support is. For important sites, it’s better to regularly back up files and databases externally as well, e.g. to a small storage device or at home. A host backup can save the day, but if data is accidentally deleted or a CMS gets hacked, having your own older backup can sometimes be worth its weight in gold.

Micha, do you use a shared backup scheme for the various projects, or do you back up the individual sites differently?

I completely agree with you about backups: What matters is not that backups are stored somewhere, but that they can actually be restored in an emergency. I’ve experienced cases where backups were available, but were only of limited use because the necessary database or file versions were missing. For important projects, regularly testing a restore in a local or separate environment would therefore be at least as important as keeping an external copy.

It’s certainly nice that the range of services included in the premium package has improved without the price increasing. Do you know whether PHP versions and databases can be updated automatically for your older projects, or do you have to initiate such changes yourself each time? Especially with several long-running sites, this could otherwise eventually turn into a maintenance headache.

Projects of the “dump the database and call it done” variety naturally work great as long as the files are actually reproducible. I wouldn’t completely exclude uploads, `.env`/configuration files, and any manually customized templates from the backup, at the very least—otherwise those are exactly the three things that are guaranteed to be nowhere to be found when you need them 😄

You can restore code cleanly via Git or an archive, so there’s no need to mirror the entire web space externally every day. For small sites, a monthly full dump plus a daily database backup might even be enough. In the end, what matters more is testing the process once and not discovering only after a crash that the backup exists, but the credentials for it have been lost in limbo since 2021.

I feel similarly about the old PHP versions as KlartextKai: great as a compatibility stopgap, but rather worrying as a permanent solution. Especially PHP 5.6 should only be run behind Basic Auth, an IP restriction, or at least without being publicly accessible. Do you know whether all-inkl displays any warnings or restrictions for the old versions, or can you simply continue selecting them without any comment?

Exactly, `.env` and manually modified files are the typical “oh right, there was still that” candidates. With uploads, it depends heavily on the project: for a small community website, you can re-upload them if necessary, but shop photos or user attachments can quickly become painful. That’s why I usually separate code (Git), the database, and persistent files, and occasionally perform a complete restore on a test subdomain.

I’d therefore view the all-inkl backups more as an additional safety net, not as the only backup. Especially in the case of accidentally deleted data, it’s useful if you can restore an older version yourself—provided the interface offers this sensibly for individual databases/directories. Do you know how long the various backup versions are actually retained there?