• Wenn du hier im Forum ein neues Thema erstellst, sind schon Punkte aufgeführt die du ausfüllen musst. Das dient im Allgemeinen dazu die notwendigen Informationen direkt mit der Frage bereitzustellen.
    Da in letzter Zeit immer wieder gerne das Formular gelöscht wurde und erst nach 3 Seiten Nachfragen die benötigten Infos für eine Hilfe kommen, werde ich nun jede Fragestellung die nicht einmal annähernd das Formular benutzt, sofort in den Sondermüll schicken.
    Füllt einfach die abgefragte Daten aus und alle können euch viel schneller helfen.

XF1+2 Bräuchte mal moralischen Beistand... ich sag nur chown -R /var/*

otto

Die 5k-Labertasche
Lizenzinhaber
Registriert
11. Dez. 2010
Beiträge
5.216
Punkte
448
XF Version
  1. 2.2.15
XF Instanz
Hosting
PHP-Version
8.2.x
MySQL/MariaDB
10.3.x
Provider/Hoster
Strato/Hetzner
Vorweg - JA - ich weiß das dies einer der dämlichsten Fehler auf Unix-Erden ist. Und ja - Backups wären dann Gold wert.
Blöderweise hab ich aus Speicherplatzgründen "nur" Backups der ganzen Domains, aber kein Server Vollbackup. Shit happens - ich gelobe Besserung.

Was hab ich getan?
Im Stress statt eines Unterordners /var gleich mal den Hauptordner /var des Systems mit einem fetten
Code:
chown -R user:gruppe /var/*
Vernichtet. :wideyed::ninja::bomb::shifty:

Da gibts nichts schön zu reden - nach 20 Jahren Unix passiert mir sowas, was eine Scheiße.

Nun gut, nach dem ersten Shock bekommt das Hirn langsam wieder Sauerstoff - also suche nach Lösungen...

Machen wir es kurz - es gibt für so eine Dämlichkeit keine wirklich gescheite oder gar einfache Lösung... es sei denn, man hat das böse verhasste Plesk auf dem Server laufen. Das kann einem den Weg zurück erstaunlicher Weise erleichtern.

Wem auch mal so was dummes passiert - das Zauberwort ist der Befehl "Plesk repair" in all seinen Facetten:
Code:
plesk repair
Siehe auch:
Plesk Reparaturdienstprogramm

Und hilfreich war auch dieser Plesk Support Artikel um sich die DB wieder geschmeidig zu machen:
Unable to log in to Plesk: Unable to connect to database: mysql_connect(): Permission denied /var/lib/mysql/mysql.sock
Sowie u.a.:
Unable to start nginx: Not starting nginx as it is disabled in config

Der Weg ist müßig und ist auch (noch) nicht komplett fertig, aber ich bin bisher zuversichtlich. Erste Domains laufen wieder, Plesk lebt und ich arbeite nun offene Fehler nach und nach ab. Bödheit muss mit Arbeit bestraft werden, ist halt so. :shifty:

Und ein gut gemeinter Rat zum Schluss:
Server Backups nicht vergessen! Nicht nur Domain-Backups machen, Serverbackups können Nerven retten!
Und Obacht in der unix Konsole - Verzeichnisse ansprechen funktioniert da halt komplett anderes als unter Windows und auch nach vielen Jahren, kann einem so ein strunz dummer Fehler passieren. Lernt draus! :shy: ;)
 
Zwischenstand:
Redis zickt noch rum (werde ich wohl einmal neu aufsetzen müssen) und ein Backend einer Software will noch nicht wieder laufen.

Ansonsten... alle Wordpress laufen wieder und auch alle Xenforo Installationen. Plesk läuft ebenfalls wieder.

Bin mir aber sicher, da kommen die nächsten Tage/Wochen noch paar Sachen zusammen die ich noch zu fixen habe dann. Aber alles in allem bin ich wohl mit nem blauen Auge davon gekommen. Ein Glück noch mal. ;-)
 
Deswegen habe ich mit einem managed System dafür gesorgt, dass ich nicht im Wechsel an Küchen und Servern rumfummeln muss. Funktioniert mit Treckern wohl auch nicht. :D

Gutes Gelingen. :cool:
 
Auch das sicherste Verkehrsmittel hat irgendwann mal nen Unfall und wenn mir das 1x alle 20 Jahre passiert, dann kann ich damit leben.

Bei managed bin ich immer wieder an Grenzen gestoßen was wohl auch an der Vielschichtigkeit der Projekte auf dem Server liegt. Es ist eben nicht nur Xenforo, oder nur Wordpress, da läuft ja noch mehr drauf und durch diesen Umstand sind meine Ansprüche recht hoch und wenn man das managed haben möchte, schlicht zu teuer.

Auch kannst du davon ausgehen, dass mir dieser Fehler nicht noch einmal passieren wird. ;)

Ich hab jetzt auch einen groben Überblick über die noch offenen Fehler und ich werde einen anderen Lösungsweg einschlagen: Server-Tausch und damit Umzug der Domains und zurück lassen alten Systems. Zum Glück mieten wir unsere Server monatlich kündbar, und zum Glück sind aktuell auch brauchbare Angebote da. Die aktuell 2x480 GB SSDs waren mir eh schon lange zu knapp so dass ich nun nach 2x TB schaue und wohl wieder bei 64 GB ECC Ram landen werde.

Zeitlich ändert das nun nichts, ich werde für den Umzug etwas so lange benötigen wie geschätzt für die Fehlerbehebung nötig wäre, wobei da noch eine gewisse Unsicherheit bei ist. Der Umzug ist hingegen wohl ebenso problemlos und flott wie vor 4 Jahren als wir den aktuellen Server mieteten.
 
Auch das sicherste Verkehrsmittel hat irgendwann mal nen Unfall und wenn mir das 1x alle 20 Jahre passiert, dann kann ich damit leben.

Falls du nicht tot bist. ;)

Aber ich verstehe was du meinst.
 
Werde nun wohl zu Hetzner mit dem Server wechseln (von 20 Jahren Strato Servern) hoffe ich bereu das nicht. Technisch ist er brauchbar:

8 echte Kerne, (16 Threads, AMD Ryzen 7 3700)
64 GB DDR4 ECC Ram
2x 960 GB NVMe SSD
Plesk
mit 1 GBit/s angebunden
2 IPv4
1 TB Backupspace (erweiterbar auf bis 20 TB)

Da geht das nächste mal chowm -R user:gruppe /var/* gleich noch schneller... har, har, har ... :D ;)
 
8 echte Kerne, (16 Threads, AMD Ryzen 7 3700)

Ja, den nutzen wir auch :D

Dann noch ein
innodb_use_atomic_writes = 1
in die mariadb.cnf damit die Datenbank richtig schnelle SSDs auch nutzt.

Tröste dich, mir ist ahnliches auch schon passiert.
Nur ging es da um rm -f /* um eine Festplatte leer zu bekommen, wobei ich die gemounteten Netzlaufwerke "übersehen" hatte.
War zwar nur privat und Backups habe ich immer, allerdings war der Schreck groß ob der damals neuen Erkenntnis, dass Root unter Linux/Unix tatsächlich ernst genommen wird und /* sich auch auf Netzlaufwerke auswirkt. ;)
Und wie schnell das ging :D

Nun noch willkommen bei Hetzner. Ein so weit guter Hoster und auch der Support ist erstklassig - so zumindest meine bisherige Erfahrung, wenn es mal mit der Hardware "geklemmt" hat.

Support für Plesk, so wie früher, gibt Hetzner seit den Preiserhöhungen nicht mehr. Da solltest du für den Umzug https://support.plesk.com/hc/en-us/articles/213953025-How-to-get-support-directly-from-Plesk- im Hinterkopf behalten.

Ebenso solltest du das kostenlose Plesk-addon
RBL Check
Version
1.1.2-1 installieren.
Sollte deine Server IP-Range in einer RBL blockiert werden bekommst du das schnell mit und bei Hetzner kann das durchaus vorkommen, dass eine ganze IP-Range (/16) blockiert wird. Dann einfach an den Support wenden.

Viel Erfolg beim Umzug...
 
Na ich bin ja schon mehrfach mit Plesk umgezogen - gruselg war das nur mit Plesk 9 und älter. Seit der 10, 11, 12 ist das erheblich einfacher geworden und das Plesk Support Forum hab ich eh fest verdrahtet im Browser. :)

Ebenso solltest du das kostenlose Plesk-addon
RBL Check
Kenne ich - läuft schon auf dem alten bei Strato und seither weiß ich wie beliebt man mit nem Strato Server bei uceprotect.net ist... :D ;)

Ok, alles weitere stimmt zuversichtlich, dass ich mit Hetzner nicht in die Scheiße greife... das doch schon mal gut. :D
 
So - Bestellung ist raus. Es wird ein AX 51 NVMe mit Plesk+Ubuntu LTS.

Als Strato-Kunde ist die Verwaltung bei Hetzner aber zum Anfang auch bisl verwirrend, aber kommt Zeit kommt Gewöhnung. :D
 
@Masetrix
Ist das normal das der bestellte Server erstmal ne Zeit aus der Bestellübersicht verschwindet ohne irgendwo sonstwo aufzutauchen oder fängt es schon gut an und ich muss Montag Nachmittag dann den Support bemühen?

Ich hatte hier eine Anzeige zum Server und den Hinweis das er in wenigen Minuten eingerichtet sei. Das hat sich Samstag nicht verändert und Sonntag war der Eintrag weg und erstmal keine Spur (auch keine Email) vom Server bisher.
upload_2022-2-20_15-14-20.png

Als Zahlung wurde Sepa gewählt und die Bestätigung per 20 Euro PayPal Vorauszahlung hab ich auch erfolgreich erledigt.

Unter Server ist bisher auch weiterhin gähnende Leere...
upload_2022-2-20_15-15-30.png

zumindest an dem Punkt muss ich sagen, ging das Prozedere bei Strato einfacher/schneller/überschaubarer. Na mal sehen ob sich Montag was bewegt dann.
 
Zuletzt bearbeitet:
Hat sich im Laufe des Tages gegeben..

Muss sagen, bei Hetzner hat man mehr Möglichkeiten, aber das macht es es klar deutlich komplexer.

Jetzt hab ich nur noch ein "Problemchen": wie rette ich meine Daten vom alten auf den neuen Server am besten?

Plesk Migration scheidet wohl leider aus, da außer über die RemoteConsole aktuell kein SSH Zugriff möglich ist - sicher irgend eine Scheiße noch mit den Rechten im /var/ Verzeichnis bzw. Unterverzeichnissen.

Also hab ich die von Plesk gefertigten Backups runter geladen (zig GB) und mit dem kleinsten einen Versuch gewagt. Ein Wordpress kaum Plugins nur 60 MB Backup für alles.
Die Dateien sind da.
Die DB ist da.
Aber Wordpress meint beharrlich:
upload_2022-2-21_17-18-3.png
Doppelt getestet die DB-Verbindung kommt zu stande, und die DB ist zumindet per phpMyAdmin lesbar und fehlerfrei. Vormals MariaDB 10.3.x und auch jetzt wieder MariaDB 10.3.x
Ich bekomm die Kriese... :(

Edit: Cacheproblem
Ich seh in den Logs gerade das er die Verbindung zur DB zum alten Server versucht aufzubauen. Die IP war verräterisch. Jemand ne flotte idee wie ich ihm das sofort abgewöhnen kann?
 
Jetzt hab ich nur noch ein "Problemchen": wie rette ich meine Daten vom alten auf den neuen Server am besten?
du kannst mit ssh und rsync einfach alles rüberkopieren und musst die dienste dann nur noch starten, in etwa so:

  1. Backup aller Daten machen / Snapshot der VM / o.Ä.
  2. rsync /var/www/* von alt auf neu; oder wo auch immer die daten liegen
  3. alle dienste auf dem alten stoppen
  4. nochmal rsync /var/www/* (abgleich von geänderten daten, sollte dann minimal sein)
  5. auf dem neuen server sollte schon installiert sein: webserver, php, mysql/mariadb server
  6. mysql auf dem neuen stoppen
  7. rsync von /var/lib/mysql/* von alt auf neu (alle Datenbanken, Dateien etc. mysql aktualisiert die dann selbst und die ganzen Benutzer/Kennwörter der Datenbank user sind noch da)
  8. msql auf neuem starten
und sofern ich nicht irgendwas vergessen habe sollte es das eigentlich schon sein

Ich seh in den Logs gerade das er die Verbindung zur DB zum alten Server versucht aufzubauen. Die IP war verräterisch. Jemand ne flotte idee wie ich ihm das sofort abgewöhnen kann?
sicher kein cache problem, eher etwas in den einstellungen in den files oder sql
 
Dass der Migrator nicht funktioniert ist Mist, denn der ist genau für derlei zuständig. Auch deine Zertifikate könnten ohne den Migrator Probleme bereiten.

Aber:

Du musst das komplette Backup auf dem neuen Server zurückspielen und dann die IPs im neuen Plesk von Hand, auf die neuen IPs ändern.
Unter /admin/ip-address/list/ stehen nach dem Restore noch die alten IPs drin, die musst du ersetzen und Plesk repair all
laufen lassen. Dabei sollten auch die Zertifikate gefixt werden.

Ansonsten hast du ja auch noch die Möglichkeit die Backups auf den neuen Server zu kopieren und den Rest, nach Schilderung des aktuellen Problems, den Plesksupport erledigen lassen.
 
Zuletzt bearbeitet:
Die Zertifikate hab ich neu erstellt, das sollte laufen (Let'sEncrypt)

Du musst das komplette Backup auf dem neuen Server zurückspielen und dann die IPs im neuen Plesk von Hand, auf die neuen IPs ändern.
Unter /admin/ip-address/list/ stehen nach dem Restore noch die alten IPs drin, die musst du ersetzen und Plesk repair all
laufen lassen. Dabei sollten auch die Zertifikate gefixt werden.
/admin/ip-adress/list/ sprichst du von der Konsole auf dem neuen Server oder soll das ein Anhängsel an die Domain in der Browseradresszeile sein? Ich steh gerade bisl aufm Schlauch, wo ich das finden oder eingeben sollte?

Was wäre, würde ich nur die DB+Dateien aus den Backups holen? Die Domain vorher neu erstellen und dann das Backup teilweise zurück spielen. So dachte ich...
 
/admin/ip-adress/list/
ist ein Anhängsel für das ACP des neue Servers. Da findest bzw. trägst du die neuen IPs ein damit plesk repair die später in die Web und Mailconfigs eintragen kann.

Ich würde die Backups vom alten Server, auf den neuen kopieren und dort "Domains, deren Dateien und zugehörige Datenbanken, sowie das Mailing und DNS wiederherstellen lassen.
Keinesfalls die Servereinstellungen des alten Servers auf dem Neuen wiederherstellen, sonst kommst du nicht mehr ans ACP des neuen Servers, weil der damit Namen und die IP des alten Servers erhalten würde.

Sind die Domains nebst Email /DNS/Datenbanken/Dateien der Domains auf dem neuen Server wiederhergestellt und die neuen IPs im AdminCP (siehe Link) im neuen Server eingetragen, "plesk repair all" per ssh laufen lassen. Das sollte die alten, durch die neuen IPs an allen benötigten Stellen ersetzen.

Wie gesagt, trivial ist das nicht, daher nochmal der Verweis auf den Plesksupport. Aber auch der benötigt Zugriff auf die Backupdaten der Domains des alten Servers.
 
Zuletzt bearbeitet:
ist ein Anhängsel für das ACP des neue Servers. Da findest bzw. trägst du die neuen IPs ein damit plesk repair die später in die Web und Mailconfigs eintragen kann.
Sind wir im Robot oder im Plesk - im Robot nehme ich an... ich schau gleich mal...

Hmm. habe es nun bei Hetzner an:
konsoleH :: Anmeldung
https://robot.your-server.de/
und meine Plesk Adresse angehangen ... an keiner Stelle findet er die angefragte Seite.
:sorry:
sonst kommst du nicht mehr ans ACP des neuen Servers, weil der damit Namen und die IP des alten Servers erhalten würde.
Also meinst du mit ACP doch Plesk?



Vielleicht mal von vorne...

Ich hab eine Domain registriert, für den Server: meine-domain.de
Ich hab bei der Serverbestellung als Hostname: s1.meine-domain.de angegeben
Und noch bevor der Server eingerichtet war in der Domainverwaltung (konsoleh....) die Subdomain s1 zusätzlich eingerichtet.
Als der Server da war, hab ich der Domain die Haupt-IP des Servers zugeteilt.
Das funktionierte auch sofort und die Platzhalterseite vom Hetznerserver wurde korrekt angezeigt. Dazu noch ein SSL Zert für die Domain damit auch Plesk sicher überträgt.

Dann hab ich im Plesk einen neuen Webspace name1.de angelegt und gleich danach die Domain name1.de (bei Strato als Domain gehostet) in den DNS Einstellungen auf die Haupt-IP des neuen Servers umgestellt. So hab ich das seit Plesk 10 eigentlich alle 2-3 Jahre beim Serverwechsel gemacht.

Neu ist nun der Weg über ein Plesk-Backup (herunter geladen und wieder hoch) statt über den Weg der Plesk Migration, da diese bisher nicht läuft weil ich mir am alten Server irgendwas am SSH Zugang zerschossen habe. Da geh ich sicher auch noch mal bei. Soviel kann da nicht hinüber sein, ich hab ja NUR ;D :D den Eigentümer und die Gruppe drüber gebügelt, zum Glück nicht die Schreib-/Leserechte.



ich denke ich kill noch mal die den ersten Versuch und nehm nen neuen Anlauf mit der ersten übernommenen Domain. Danke für jeden noch so kleinen Tipp/Hinweis der mich am Ende wieder zurück ins Rennen bringt. :)
 
Keinesfalls die Servereinstellungen des alten Servers auf dem Neuen wiederherstellen, sonst kommst du nicht mehr ans ACP des neuen Servers, weil der damit Namen und die IP des alten Servers erhalten würde.
Naja - noch ist ja nichts drauf. Zur Not einmal neu von ganz vorne... Betriebssystem und Plesk drauf drücken. ;) Hab mich lange nicht so abmühen müssen bei nem Serverwechsel... aber da muss ich nun durch.
 
Zur Not auch gern per PN weiter... da kann man leichter mal paar Screenshots zusenden als hier gleich öffentlich die Hosen runter zu lassen. ;)
 
upload_2022-2-21_20-34-25.png

Systembenutzer (FTP-Benutzer)
IP (Haupt-IP des neuen Servers)
sind auf dem neuen korrekt im Plesk. da stand auch nie die des alten Servers. Kanns sein dass das eher ein DNS-Cache Problem ist und morgen lacht die Sonne wieder und es geht?

Korrektur - geht heute schon und laut MX-Tools auch mit der korrekten IP. Aber in den Logs im Plesk, in den Protokollen der betreffenden Domain...
upload_2022-2-21_20-38-1.png
Ist nach wie vor nur die alte IP bei den Zugriffen zu sehen.
 
Zurück
Oben