Eine Seperate grub Partion ist nicht notwendig, wenn man es macht wie ich es beschrieben habe. (und ich verwende ebenfalls gpt)
Ähm, OK, dann bist du halt auf der Schiene:
Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged.
War mir nicht klar, daß du das explizit so haben willst.
Die Grub Partition tut nicht weh...
2 Partitionen, eine unverschlüsselte boot partition und eine luks2 verschlüsselte Partion
Hab ich auch so...
mit grub-install --force die blocklist installation erzwungen (macht er sonst nicht mehr)
...das allerdings nicht. grub-install geht problemlos wie es soll?
Bei GPT Partitionierung ist halt noch eine bios_grub Partition dabei. Sollte bei msdos Partition auch ohne gehen...
# parted -l
Model: QEMU QEMU HARDDISK (scsi)
Disk /dev/sda: 21.5GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: pmbr_boot
Number Start End Size File system Name Flags
1 32.8kB 1049kB 1016kB grub bios_grub
2 1049kB 268MB 267MB ext2 boot
3 268MB 21.5GB 21.2GB luks# grub-install /dev/sda
Installing for i386-pc platform.
Installation finished. No error reported.2) Hat es eigentlich eine (reduzierende) Auswirkung auf die snapshot-Möglichkeiten im SCP, was den zu Verfügung stehenden Platz angeht, wenn man lvm dazwischen legt?
Platz hast du wenn du fstrim machst (sonst nur das wo noch nie geschrieben wurde - ob Nullen erkannt werden habe ich nicht ausprobiert). fstrim bügelt freien Speicher weg. Gelöschte Dateien lassen sich dann aber nicht wieder herstellen.
Mit issue_discards=1 in lvm.conf macht LVM auch TRIM wenn du ein LV löschst oder verkleinerst oder sonstwie verschiebst so daß vorher belegte Extents im LVM frei werden. Falsche lvresize-Befehle lassen sich dann aber nicht rückgängig machen (anhand /etc/lvm/{backup,archive}/), die Daten sind dann schon weg, wenn das Dateisystem größer als das LV war.
Daher lieber issue_discards=0 in lvm.conf und bei Bedarf den freien LVM-Speicher von Hand wegbügeln
lvcreate -l100%FREE -n discard deinevg
blkdiscard /dev/deinevg/discard
lvremove deinevg/discardWenn du deine VGs voll belegst (0 free extents) dann ist das hinfällig und fstrim reicht.
Falls du was mit Verschlüsselung (cryptsetup) machst, das braucht ein --allow-discards damit fstrim durchgeht.
Ich nutze selbst nginx seit Ewigkeiten und eigentlich auch nur, weil ich bei Apache den Konfigurationsdschungel nie so 100% durchblickt habe. Und davon daß man Apache überhaupt nicht benutzt wird es natürlich nicht besser.
Aber das soll keine Empfehlung für nginx sein. Das ist ein sehr leistungsfähiger Webserver, mit sehr unintuitiver Konfiguration. Bei nginx geht ziemlich leicht ziemlich viel schief, der Teufel steckt im Detail... plötzlich hat der falsche Server- oder Location-Block Vorrang oder eine Anweisung wird ganz ausgehebelt, und php führt die falschen Dateien (nicht) aus. nginx pitfalls und nginx if is evil (muss jeder gelesen haben) ist da nur ein Teil davon. Von der Dokumentation her wird das oft nicht klar, und man findet erst im nginx Forum oder Bugtracker was dazu.
Ich habe ein kleines Shellscript das für alle Domains und Subdomains, HTTP wie HTTPS, diverse Dinge abfragt (ganz banal mit curl | grep). Fehlercodes, Umleitungen, Header, Inhalte, Sonderregeln müssen stimmen. Und bei jeder noch so kleinen Konfigurationsänderung wird damit einmal alles durchgetestet. Zusätzlich zum regulären Monitoring, das (in der Regel) nur eine Seite abfragt um zu schauen ob das Ding überhaupt online ist.
Anders kann man es kaum zuverlässig betreiben. Praktisch jede nginx-Konfiguration hat irgendwelche Fehler. Gerade wollte ich forum.nginx.org aufrufen und... HTTPS-Zertifikat abgelaufen. 
Der Test der da bei mir spätestens 3 Wochen vorher warnt, der fehlt in meiner Konfiguration auch noch... seufz.
EDIT:
tl;dr Dem Besucher ist es egal, mit was deine Seite läuft. Spielen kann man immer aber wenns läuft, dann spricht auch nichts dagegen, es einfach so zu lassen.
Habt ihr eure Datenbanken auf dem Webserver (also lokal), oder auf einem 2. Server ?
Wenn es nicht lokal läuft, dann muss auf einmal alles übers Netzwerk. Da kann es schnell mal Probleme mit der Bandbreite geben und mit Latenzen, die sich summieren weil es ja meistens nicht bei der 1 DB-Abfrage bleibt. Ein 2. Server bringt keinen Geschwindigkeitsvorteil sondern erstmal nur Nachteile. Das lohnt sich nur wenn die Anwendung drauf optimiert ist oder anderweitig so stark profitiert daß die Nachteile ausgeglichen werden.
Mir ist auch immer noch nicht klar, ob es überhaupt wichtig ist, von VIRTIO auf SCSI umzustellen, also was das bringt?
Wenn bei dir alles funktioniert dann gibts auch keinen Grund zum wechseln.
Bei mir gabs mal richtig fiese Hänger mit virtio (cpu stuck) und seitdem stehts auf scsi... aber das ist eine Ewigkeit her.
Domain ist eine .COM
Das wär ganz gut das vorher zu erwähnen... bei COM ist es wichtig das nicht erst auf den letzten Drücker zu machen.
Bei dem Kündigungstermin (einer DE-Domain) geht es ja um die Jahresgebühr. Wenn du die Domain rechtzeitig mit dem Authcode wegziehst, hat sich das ohnehin erledigt. Netcup kann ja keine Domain verlängern die nicht mehr bei Netcup liegt (es sei denn vielleicht man will das als externe DNS-Server verkaufen). Kündigung ist so gesehen ein Löschauftrag.
Wenn du draufklickst kommt da auch so ein Popup "Sie beauftragen uns mit der Kündigung die Domain zu löschen. Die Domain ist dann nicht weiter nutzbar und kann nach der Löschung auch nicht zu einem anderen Anbieter übertragen werden. Beachten Sie, dass zum Kündigungsdatum alle mit dieser Domain genutzten Dienste nicht mehr erreichbar sind ..."
Ich würd das nicht kündigen, entweder du ziehst um oder die Domain wird eben nochmal für ein Jahr bei Netcup bezahlt, das ist ja ein vertretbares finanzielles Risiko. Umzug vergessen oder krankheitsbedingt doch nicht durchführen können und die Domain verlieren weil ein Löschauftrag in der Warteschleife ist, das wär dann ziemlich dumm gelaufen.
Manchmal muss man dem Webserver einen Tritt verpassen z.B. mehrere laufende Worker-Prozesse, von denen einer warum auch immer noch das alte Zertifikat ausliefert. Einfach mal alles ordentlich neu durchladen und mit etwas Glück ...
nicht ausgeschaltet aber direkt ins rescue-system wäre schick
den ssh-publickey dafür schon beim bestellvorgang reinpasten... und ab gehts
würde einen ordentlichen ersteindruck machen, aber na ja, bislang wars auch kein problem das von hand
Mit Linux wär das nicht passiert... 
Es geht ja erstmal darum, überhaupt ein Backup zu haben. Wie man das dann hochlädt, das ist ein lösbares Problem. Wenn man es gar nicht hat, dann unlösbar.
Kommt auch auf die Datenmenge an, wer eine 100TB Mediathek betreibt, der kommt nicht umhin, als das auf dem Postweg "hochzuladen" oder selber ins RZ zu fahren.
Und ansonsten kann man sich klar einfach noch eine andere Kiste irgendwo mieten zum spiegeln, aber bei 10GB ist das jetzt noch nicht so angesagt...
Nebenbei, das "nach Hause runterladen" soll dich nicht davon abhalten, auf dem Server selber auch den Zustand der letzten 7 Tage / Wochen vorzuhalten. (Solang du den Speicherplatz nicht anderweitig nutzt.)
Streng genommen ist das kein Backup weil auf der gleichen Maschine, auf dem gleichen Speichermedium, und wenn das eingeht ist ja alles auf einmal weg.
Aber manchmal muss man ja einfach so z.B. "auf den Stand von gestern" zurückgreifen können. Ohne dafür erst was hoch- oder runterladen zu müssen.
10GB? rsync nach Hause...
wenn du die tabelle nicht löschen kannst, vielleicht geht umbenennen noch?
Dann aber festgestellt, dass scheinbar nicht mit UTF-8-Zeichensatz importiert wurde - die Umlaute wurden falsch dargestellt.
Im Dump selbst sind die Zeichen aber richtig?
Ich hatte mal den "Spaß" bei einem anderen Webhoster. Die hatten eine alte MySQL Installation (ohne utf8mb4, also ohne emoji und pipapoh) aber zu dem Zweck auch eine MariaDB. Leider stammte das 'mysqldump' Tool vom veralteten MySQL und das hat brav aus der MariaDB-utf8mb4 Datenbank einen Dump erzeugt und völlig fehlerlos alles in Ascii-?-Fragezeichen verwandelt. Der Dump war unbrauchbar und es war mein Glück, daß ich es beim Umzug bemerkt habe...
Solang die Zeichen im Dump richtig sind, manchmal reicht es dann aus, das Charset im Dump selbst anzugeben ( wenn nicht eh schon der Fall )
Wenn die DB selber gar nicht mehr reagiert wirst wohl bei Netcup nachhaken müssen
Viel Erfolg
es wird dir nicht viel anderes übrig bleiben
php 5 wird seit bald 2 jahren nicht mehr aktiv unterstützt und es gibt jetzt auch keine patches für kritische sicherheitslücken mehr
und das problem mit froxlor und php5 soll gelöst sein ... https://github.com/Froxlor/Froxlor/issues/559
umgekehrt würd ich da eher erwarten, daß froxlor probleme mit php5 hat oder haben wird, weil - das eben "keiner mehr benutzt"...? (benutzen sollte)
Fakt ist, da dass System ja 24/7 läuft, werde ich mir primär eine WD Red 3TB Platte kaufen und verbauen.
Nach Adam Ries bezahle ich aber, wenn ich mir eine zweite WD Red kaufe, statt nur 100€ schnell mal 200€ für meine Platten
Für mein Zuhause-RAID bin ich dieses Jahr von uralten 2TB- auf 8TB-Platten umgestiegen, WD80EZAZ aus WD MyBooks, gabs dieses Jahr mehrmals zu einem TB-Preis deutlich unter 20€. Gehäuse und Netzteil noch gratis obendrauf.
100€ für eine 3TB-Platte (30€+/TB) ist doch der helle Wahnsinn. Die teuren Festplatten gehen auch kaputt, davon kann man sich nicht freikaufen.
Das 0815-RAID zuhause ist auch kein 24/7 Betrieb sondern 24/7 idle.
Spiegelung ist okay solange diese auf Dateibasis erfolgt (rsync, borgbackup o.ä.)
Mit entsprechender TTL ist auch das kein großes Problem... (und du musst die alte IP ja nicht sofort abdrehen)
Aber wie auch immer. Sorry fürs abdriften. 
Wie die Datei formatiert sein muss, darum gehts ja gar nicht. Aber man sollte mehrere IP-Adressen eben einfach so angeben können, ohne dafür irgenwelche komischen Verrenkungen machen zu müssen, wie bei Debian der Fall. Aber ist halt so. 
Bei Debian hat sich die Variante mit den vielen up/down Befehlen für mich als die praktikabelste erwiesen. Schaut halt komisch aus. ymmv
Und Bugs hat das Debian System auch zur Genüge. Im laufenden System die IP-Konfiguration ändern hat da nicht so gut geklappt. Im Zweifel Reboot notwendig, oder von Hand machen.
Den zweiten Teil mit dem Programm, das nach jeder Neuinstallation eine neue IP braucht, hab ich nicht so recht verstanden. In Zeiten von IPv4 Knappheit klingt das eigentlich kontraproduktiv, IPv4s auf sowas zu verschwenden. Bei IPv6 wärs ja kein Problem, da kannst du dir jeden Tag eine neue IP würfeln wenns sein muss.
