all-inkl.com - Preisstabil seit 2017

14 Jahre beim selben Hoster ist eigentlich das bessere Qualitätssiegel als jede Werbeaussage :) Wenn in der Zeit weder Preis noch Support oder Technik so genervt haben, dass man umziehen will, machen sie offenbar einiges richtig.

Bei der Provision würde ich aber immer schauen, ob sie nur für die erste Bestellung gilt und was bei Widerruf/Kündigung passiert – die sechs Wochen klingen nach der üblichen Wartezeit dafür. Weißt du noch, welches Paket du damals genommen hast und ob sich dessen Leistungsumfang über die Jahre verändert hat?

Das klingt nach dem besten Kompliment für einen Hoster: Seit 14 Jahren läuft alles, der Preis bleibt fair und wenn doch mal was klemmt, ist der Support da. Gerade mehrere Projekte auf einem Paket zu bündeln, macht den unveränderten Preis ja noch angenehmer.

Wäre nur interessant, ob sie inzwischen auch bei Themen wie PHP-Versionen, Backups und IPv6 so unkompliziert mitziehen. Aber „man merkt den Hoster kaum“ ist bei dem Thema wirklich Gold wert.

Gerade bei mehreren Projekten merkt man erst, ob ein Paket langfristig taugt. Nicht nur wegen Speicher und Domains, sondern auch bei den eher unsichtbaren Dingen: aktuelle PHP-Versionen, Datenbank-Updates, SSL-Zertifikate und ein brauchbares Backup-Konzept. Wenn das alles ohne ständiges Nachbuchen oder Basteln mitwächst, ist ein seit Jahren gleicher Preis tatsächlich ziemlich stark.

Beim Backup würde ich mich trotzdem nie *nur* auf den Hoster verlassen – egal wie zuverlässig der Support ist. Für wichtige Seiten lieber zusätzlich regelmäßig Dateien und Datenbanken extern sichern, z. B. auf einen kleinen Storage oder zuhause. Ein Hoster-Backup rettet viel, aber bei versehentlich gelöschten Daten oder einem gehackten CMS ist eine eigene, ältere Sicherung manchmal Gold wert.

Micha, nutzt du bei den mehreren Projekten ein gemeinsames Backup-Schema oder sicherst du die einzelnen Seiten unterschiedlich?

Bei den Backups bin ich ganz bei dir: Entscheidend ist nicht, dass irgendwo Sicherungen liegen, sondern dass man sie im Ernstfall auch zurückspielen kann. Ich habe schon erlebt, dass Backups zwar vorhanden waren, aber wegen fehlender Datenbank- oder Dateiversionen nur eingeschränkt brauchbar waren. Ein regelmäßiger Test-Restore auf einer lokalen oder separaten Umgebung wäre bei wichtigen Projekten daher mindestens so wichtig wie die externe Kopie.

Dass sich der Leistungsumfang beim Premium-Paket verbessert hat, ohne dass der Preis hochging, ist natürlich angenehm. Weißt du, ob bei deinen älteren Projekten PHP-Versionen und Datenbanken automatisch aktualisiert werden können, oder muss man solche Umstellungen jeweils selbst anstoßen? Gerade bei mehreren lang laufenden Seiten kann das sonst irgendwann zur Wartungsbaustelle werden.

Bei solchen „Datenbank drauf und fertig“-Projekten funktioniert das natürlich prima, solange die Dateien wirklich reproduzierbar sind. Ich würde zumindest Uploads, `.env`/Konfigurationsdateien und irgendwelche manuell angepassten Templates nicht komplett aus dem Backup streichen – genau die drei Dinge liegen sonst garantiert nirgendwo mehr rum, wenn man sie braucht 😄

Code kann man ja sauber über Git oder ein Archiv wiederherstellen, dann muss nicht jeden Tag der komplette Webspace extern gespiegelt werden. Für kleine Seiten reicht vielleicht sogar ein monatlicher Komplettdump plus tägliches Datenbankbackup. Wichtig ist am Ende eher, dass man den Ablauf einmal testet und nicht erst beim Crash feststellt, dass das Backup zwar existiert, aber die Zugangsdaten dazu seit 2021 im Nirwana liegen.

Bei den alten PHP-Versionen sehe ich es ähnlich wie KlartextKai: als Kompatibilitätskrücke super, als Dauerlösung eher Bauchschmerzen. Gerade PHP 5.6 würde ich nur noch hinter Basic Auth, IP-Sperre oder zumindest nicht öffentlich erreichbar laufen lassen. Weißt du, ob all-inkl bei den alten Versionen irgendwelche Warnungen oder Einschränkungen einblendet, oder kann man die einfach kommentarlos weiter auswählen?

Genau, `.env` und manuell angepasste Dateien sind die typischen „ach stimmt, da war ja noch was“-Kandidaten. Bei Uploads kommt’s stark aufs Projekt an: Bei einer kleinen Vereinsseite kann man die notfalls neu hochladen, bei Shop-Fotos oder Nutzeranhängen wird’s schnell schmerzhaft. Ich trenne deshalb meist zwischen Code (Git), Datenbank und persistenten Dateien und mache gelegentlich einen kompletten Restore auf einer Test-Subdomain.

Die all-inkl-Backups würde ich dabei eher als zusätzliche Rettungsebene sehen, nicht als einziges Backup. Gerade bei versehentlich gelöschten Daten ist es praktisch, wenn man selbst einen älteren Stand zurückholen kann – sofern die Oberfläche das für einzelne Datenbanken/Verzeichnisse vernünftig anbietet. Weißt du, wie lange die verschiedenen Backup-Stände dort tatsächlich vorgehalten werden?