fstrim bei Root-Server v5

  • Hallo,


    ich habe einen Server der Generation 5 mit einer SSD-Platte. Treiber habe ich bereits auf SCSI umgestellt. Server wurde abgeschaltet und neugestartet.


    Ich kann allerdings nicht den Befehl fstrim ausführen. Ich erhalte immer die Fehlermeldung

    Code
    1. fstrim: /: the discard operation is not supported

    Wie kann ich den Befehl zum Laufen bringen?


    Ich brauche das dringend, um Platz für einen Snapshot zu bekommen, da ich den Server wechseln werde.


    Danke euch!

  • Wenn der neue Server einige Tage parallel läuft könntest du auch mittels dd migrieren. Einfach beide Server in den Rettungsmodus und dann per ssh die Daten vom alten auf den neuen Server tunneln. So hab ich's vor kurzem bei nem Server gemacht.

  • Ich habe im Frühling einen vServer mit Clonezilla direkt übers Netzwerk gespiegelt (Partitionen kopiert, da die Zieldisk kleiner ist als die Quelldisk, welche aber wiederum nicht voll belegt war).


    Nachher noch Sachen wie hostname, statische IP / Gateway, Keys etc anpassen.


    War recht schnell erledigt und ohne zusätzlichen Export.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus

  • Danke! Wie hast du denn das genau gemacht? Gibt es spezielle Dinge zu beachten, wenn ich die Daten migriert habe?


    Habe schon einmal mit rsync migriert, war aber fummelig und ich möchte das nicht mehr durchmachen.

    Also meine Durchführung lehnt sich an der hier an: https://www.linode.com/docs/pl…ing-a-disk-image-over-ssh

    Nur, dass ich eben kein img erstellt habe, sondern direkt die Daten bitweise von der Festplatte des alten Servers auf die Festplatte des neuen Servers geklont habe. Ich hatte im Endeffekt somit eine 1:1-Kopie der alten Festplatte auf dem neuen Server.

    Voraussetzung dafür ist eigentlich nur, dass die Zielfestplatte mind. genauso groß ist, wie die Quellfestplatte! Ist sie sogar größer, kannst du deine Partition ja nachträglich noch erweitern, um den ungenutzten Speicher ebenfalls zu nutzen.


    Der Vorgang war wie folgt:

    1. Beide Server in den Rettungsmodus. Auf dem Quellserver musst du den root-Zugriff per SSH zulassen. Ist zwar nicht best-practice, mit einem starken Root-Passwort oder gar pubkey-Auth im Rettungssystem sollte das aber für die kurze Dauer des Transfers kein Problem sein. Extra Pubkey einzurichten im Rettungssystem halte ich für den Fall eigentlich sogar für overkill! Sollte aber jeder für sich selbst entscheiden.

    2. Auf dem Zielsystem folgendes ausführen:

    Code
    1. ssh root@<QuellIP> "dd if=/dev/sda bs=1M " | dd of=/dev/sda bs=1M

    Dieser Befehl schickt dir die binären Festplattendaten in Blöcken von 1MB direkt von der Quell- auf die Zielplatte.

    VORSICHT: bloß nicht Quelle und Ziel vertauschen, sonst löschst du deine Daten unwiederbringlich! Also doppelt und dreifach checken!

    Außerdem musst du aufpassen, dass die Gerätenamen stimmen (/dev/sda), vorher am besten auch jeweils auf jedem System per fdisk -l checken!

    3. Warten bis der Vorgang beendet ist (angezeigt wird am Ende eine Meldung, wieviele Records übertragen wurden, dies sollte der Festplattengröße in MB entsprechen)

    4. Bei statischer IP-Konfig im Rettungssystem auf dem Zielserver die root-Partition (z. B. /dev/sda1) ins Verzeichnis /mnt mounten und die /etc/network/interfaces an die IP-Einstellungen des neuen Servers anpassen.

    5. Rettungsmodus beenden, etwaige weitere Einstellungen/Umstellungen am neuen Server wie gewohnt vornehmen. Dieser sollte jetzt normal laufen!


    Nach beenden des Rettungsmodus ist der root-Zugriff auf SSH natürlich wieder inaktiv, dieser gilt ja nur solange das Rettungssystem gebootet ist!


    Hoffe es geht bei dir genauso problemlos ;)

  • 1. Beide Server in den Rettungsmodus. Auf dem Quellserver musst du den root-Zugriff per SSH zulassen. Ist zwar nicht best-practice, mit einem starken Root-Passwort oder gar pubkey-Auth im Rettungssystem sollte das aber für die kurze Dauer des Transfers kein Problem sein.

    Das kann man ja dahingehend absichern, indem man sshd_config mit

    Code
    1. AllowUsers root@remote-ip

    einschränkt.

    CentOS 7 / nginx / php-fpm / postfix / rspamd / clamav / dovecot / nextcloud running on RS 1000 SSDx4 G8 / VPS 500 G8 / VPS 2000 G8 Plus