Hat ein Core-Modul all mein Inhalt gelöscht?

Ohne die PHP-Fehler-Meldung des Servers läßt sich das Geschehen nicht analysieren. Meine Vermutung: Du hast ohne composer gearbeitet und Dein Media-Modul hat Abhängigkeiten, die bei Dir fehlten. Composer würde das vorhandene PHP und die Randbedingungen prüfen und entsprechende Fehlermeldungen generieren. Bei Fehlern wie bei Deinem muß man immer den Grund ermitteln, sonst gibt es unvorhersehbare Resultate.

Seit Drupal 8 baut dieses auf Symfony auf. Das hat viele neue Möglichkeiten aber auch ein größere Komplexität gebracht. Die Frage "Was kann da passiert sein?" lässt sich wirklich nur höchst spekulativ beantworten. Denn schon Punkt eins der Liste gibt keine Antwort auf das "Wie" in "welcher" Server- (bzw. Hosting)-Umgebung. Es war auch schon vor Drupal 8 ratsam, nicht einfach auf einem Ziel/Propduktiv-Server einfach irgendwie etwas zu installieren, sondern ein Code-Management am besten via Git zu machen. Wenn man auf dem Ziel-Server kein Composer nutzen möchte oder kann, kann man auch den kompletten Code ins Repo holen, was auch vor und Nachteile hat. Daß hier vllt. Abhängigkeiten fehlten wäre ein Möglichkeit. Aber bevor ich hier die Datenbank (in meinem Fall dann erstmal auf einem Entwicklungs-Server) wieder gelöscht hätte, hätte ich mir diese auch angeschaut, ob tatsächlich die zuerst erstellten Inhalte komplett gelöscht wurden (mit Blick in Datenbank) oder einfach nur nicht mehr angezeigt werden könnten. In jedem Fall stimme ich Werner zu, daß Fehlerlogs sehr hilfreich wären, um hier weiter zu kommen.
Es ist auch nicht sicher, daß hier Core-Modul die Fehler-Quelle ist. Wenn z.B. zu wenig Arbeitsspeicher vorhanden ist, kann es auch einfach sein, daß es mit der Aktivierung auch nur eines weiteren Moduls zu viel wurde.

Und Generell: Auch wenn man nur Core-Module benutzt, ist es ratsam, vor jeglicher Konfiguration-Änderung, Backups zu erstellen. Denn insbesondere Modul-Aktivierungen oder das Anlegen neuere Felder etc. ziehen Datenbank-Änderungen nach sich, die wie auch die update-funktion (die man am besten auch per Drusch auslöst). Gerade das Config-Management von D9/10 erlaub es uns bequem alle Anpassungen mit Cor und Contrib-Modulen auf Arbeits-Systemen zu testen, auch diese via Repo (git) zu sichern, dessen Rollout noch mal zu testen und dann nach Einschlagen des Maintenance Modes und nochmaligem Backup in einem Produktiv-System zu importieren und dann weiter zu machen. Und wenn man ein Backup zurück spielt, sollte am besten die Datenbank zuvor gelöscht werden, weil von vorherigen Konfigruations- Rollout-Versuchen noch verwaiste Tabellen existieren können. Das kollidiert dann - wenn man Pech hat - beim nächsten Rollout-Versuch.

Das Media-Modul arbeitet mit Dateien. Wir haben nicht selten zunächst schwer analysierbare Fehler, die sich am Ende auf Fehlern im Datei-System bezüglich Schreib/Lese-Rechte oder voll gelaufene Datei-Systeme für den benutzte tmp-Ordner heraus stellen.