Auf größeren Server upgraden - Leider doch nicht so einfach

Ich habe einen V-Server. Dieser wird gut genutzt und bald reicht der Speicher nicht mehr aus.

Daher möchte ich ihn vergrößern. Eigentlich eine ziemlich simples Anliegen - dachte ich jedenfalls.

Es gibt keine Möglichkeit ihn direkt zu Rescalen, wie bei anderen Anbietern. Schade, aber damit kann ich leben, es gibt im SCP ja noch die Möglichkeit ein Festplattenimage zu erstellen, was ich dann bei einem anderen (größeren) Server einbinden kann. Somit wären die zur Verfügung stehenden Ressourcen recht schnell vergrößert.

Jetzt kommt allerdings der Knaller: Das Image erstellen geht jedoch nicht bei einem Server der fast voll ist, dies geht nur bis 50%.

Aber ein Server der fast voll ist, ist ein Grund für mich, auf einen größeren zu wechseln.

Bei Support erklärte man mir ich könnte den ja aufräumen? Wenn das mein Ziel aber wäre, dann würde ich nicht ein Upgrade auf einen mit mehr Speicher wollen.

Also bleibt mir als letzte Lösung nur auf beiden Servern ein Rettungssytem booten und dann die komplette Festplatte Blockweise rüber zu kopieren.

Dies bedeutet dann aber eine größere (und vor allem unnötige, weil eigentlich vermeidbare) Downtime, wo der eigentliche Inhalt nicht erreichbar ist.

Fast so, als sei es bei Netcup nicht gewollt, dass Kunden ein Upgrade durchführen und mehr Geld da lassen.

Schade, das ist das erste mal seit Jahren, dass ich bei Netcup enttäuscht bin.

Vielleicht überdenkt man diese Entscheidung mit den 50% in Zukunft mal und bietet dem Kunden zumindest die Möglichkeit ein Image für wenige Stunden für den Umzug zu erstellen oder als Add-On zusätzlichen Image Storage hinzu zu buchen, wenn es schon nicht möglich ist, die Festplatte direkt in eine neue VM zu übernehmen.

Würde mich jedenfalls sehr freuen.

Es handelt sich um einen VPS 500 G10s. Im CCP wird mit als einzige Upgrademöglichkeit ein VPS 500 G10s iv für den selben Preis angeboten. Sonst leider nichts.

Zitat von frank_m

Alternativ kannst du dir kurzfristig externen Speicherplatz holen.

Wie oder wo ginge das? Was kostet das und kann ich damit dann auch mein Festplatten Image erstellen ohne dass ich die komplette Festplatte einmal mit maximal 1 Gbit durchs Netz bzw RZ schieben muss?

Zitat von frank_m

Blockweise muss ja nicht sein, da gibt es schnellere Möglichkeiten. Einige Anleitungen dazu gibt es hier im Forum, vielleicht auch im Wiki.

Aber der Umstand, dass es diese Anleitungen gibt, zeigt dir: Das ist der Weg, wenn du mehr als 50% deines Speichers belegt hast.

So oder so habe ich fast die Maximalgröße der Platte an Daten, die ich dann mit maximal 1Gbit rumschieben muss. Erzeugt dann halt eine Downtime von mehr als ein paar Minuten nur, nach Möglichkeit würde ich das halt gerne vermeiden.

Zitat von KB19

Ok, das ist natürlich doof. Dann bleibt Dir wohl wirklich nur ein Transfer der ganzen SSD (z.B. mit dd | ssh) oder mit rsync. Letzteres hätte den Vorteil, dass Du es während dem Betrieb mehrfach machen kannst und somit am Ende, direkt vor dem finalen Umschalten, nur noch die letzten Änderungen synchronisieren musst. Das sollte sehr rasch gehen. Die entsprechenden Serverdienste sollten vor dem finalen Transfer natürlich gestoppt werden, das gilt insbesondere für Datenbanken.

Als wirklichen Nachteil sehe ich die Übertragung ohne Snapshot allerdings nicht, weil ein Snapshot für eine ähnliche Downtime sorgen würde. Online-Snapshots sollte man alleine schon aus Konsistenzgründen eher vermeiden.

Da es sich um einen Dienst handelt, der auf eine Datenbank aufsetzt lässt sich das nicht im Livebetrieb erledigen, die muss dafür aus. Online Snapshots sind dafür natürlich ungeeignet, mir würde es ja schon reichen wenn ich den Server runterfahre und dann an das qcow2 bzw raw Festplattenimage rankommen würde, was ich einfach in den anderen einhängen kann. Aber selbst das geht ja nicht wenn der Server voll ist und vergrößert werden soll, sondern ich dann bin ich (neben dem Technischen Wissen, wie ich den Umzug am schnellsten sinnvoll über die Bühne bringe) an die Geschwindigkeitsbegrenzung von 1000 Mbit/s gehalten, was den Prozess halt verlängert (und bei jedem Umzug mit größerer Platte noch länger dauern wird dann).

Ist halt wenn man es mit der Konkurrenz (zum Beispiel die mit dem rotem H im Logo) vergleicht wo man im Kundenpanel einfach die nächst größere Stufe auswählen kann und nach einem Reboot sind die neuen Ressourcen dann da, absolut nicht vergleichbar vom Komfort für die Kunden.

Zitat von frank_m

Nein, ein Image kannst du nicht erstellen. Am Verschieben der Daten übers Netz wird so oder so kein Weg vorbeiführen.

Storage Angebote gibt es viele. Azure, Google, S3 oder die Storage Box beim Roten H. So ein zeitbasiertes Angebot bei den großen Cloud Anbietern könnte für dich interessant sein, da du den Speicher nur kurz benötigst. Quasi rein und wieder raus.

Ah, gar nicht bei Netcup meinst du. Ja, nee dann ist das für mein Vorhaben eher uninteressant, da der Server ja eh einmal aus muss um die Daten wegzukopieren und dann kann ich sie ja auch direkt auf den neuen dann kopieren.

Zitat von gunnarh

Andere Frage: Wie erstellst Du denn derzeit Dein Backup?

Was würdest Du denn tun, wenn Dein Server heute unerwartet "crasht" (z.B. defektes Host-System, Disk-Image beschädigt, nicht mehr zu retten).

Dann müsstest du ja aus Deinem Backup auch irgendwie Bare-Metal-restoren?

Ich sichere z.B. mit VEEAM auf einen bei einem anderen Anbieter liegenden CIFS-Storage.

Restore funktioniert durch Einlegen des VEEAM.iso Image und mount des CIFS-Storage + entsprechender Wartezeit. Letzteres teste ich ab und an mal in einer VM zuhause.

Alles anzeigen

Etwas offtopic das Thema: Um Backups wird sich mit restic gekümmert. Alles erforderliche, also die Benutzerdaten sowie das Datenbankdump werden auf einen anderen Host (der nicht bei Netcup steht) gesichert, die komplette Config des Servers die zum Installieren benötigt wird, liegt in einem git. Die Sache ist nur folgende: Ein Restore ist damit problemlos möglich, allerdings dauert eine Neuinstallation auch vielleicht grob geschätzt eine Stunde, das ist halt auch Downtime die man nicht haben will. Im Worst-Case nimmt man das natürlich hin, aber für einfach nur ein Resize der Festplatte finde ich diese Zeit alles andere als angemessen.

Zitat von aRaphael

Tatsächlich hatte ich vor demnächst ähnliches über mein Backup zu lösen.

Ich habe auf einem Server auch über 50%, allerdings sind das ja überwiegend Daten und nicht System.

Also: Backup der Daten. Server vom Netz. Dickes Datenverzeichnis löschen. Snapshot erstellen. Daten wieder einspielen. (Tatsächlich kann man nämlich seinen Speicherplatz wieder vollknallen, nachdem man den Snapshot erstellt hat )

Das ist nur eine relativ kurze Downtime und ich kann dann in aller Ruhe den Snapshot übertragen und auch dort das Backup wieder einspielen.

Bei mir ist es halt keine Datensammlung in einem losen Verzeichnis, sondern quasi ein einzelner Dienst. Da drin rumlöschen ist halt auch irgendwie blöd (abgesehen davon, dass die Datenbank dafür eh aus sein müsste um nicht kaputt zu gehen und dann auch wieder nicht erreichbar wäre)

Zumal Speicherplatz optimieren ja nur dann funktioniert, wenn man kein LUKS o.ä. nutzt und der Hypervisor dann nicht genutzten Speicher auch als solchen erkennen kann. Sobald man mit LUKS einmal drüber ist, hat man dann eh quasi verloren