Jump to content

Anleitung:Backup eines Wikis

From mediawiki.org
This page is a translated version of the page Manual:Backing up a wiki and the translation is 100% complete.

Es ist wichtig, regelmäßige Sicherungen (engl.: Backup, pl.: Backups) der Daten in ihrem Wiki zu machen. Diese Seite bietet einen Überblick über den Sicherungsvorgang für einen typischen MediaWiki-Wiki; möglicherweise möchten Sie Ihre eigenen Sicherungsskripte oder Zeitpläne anlegen, die an die Größe Ihres Wikis und Ihre individuellen Bedürfnisse angepasst sind.

Hilfe:Export ist eine alternative, einfache und schnelle Methode, um lediglich die Inhaltsseiten des Wikis zu speichern anstelle der vollständigen Datenbank.

Übersicht

MediaWiki speichert wichtige Daten an zwei Orten:

Datenbank
Seiten und ihr Inhalt, Benutzer und ihre Einstellungen, Metadaten, den Suchindex usw.
Dateisystem
Konfigurationsdateien, angepasste Skins, Erweiterungen, Bilder (inkl. gelöschte Bilder) usw.

Sie sollten in Erwägung ziehen, Ihr Wiki vor der Datensicherung auf read-only zu setzen, also vor Veränderung zu schützen — siehe auch $wgReadOnly . Dadurch wird sichergestellt, dass alle Teile der Datensicherung vollständig und konsistent sind.

Datenübertragung

Für die Übertragung des Backups vom Server stehen folgende Möglichkeiten zur Verfügung:

  • Nicht-private Daten können einfach auf archive.org veröffentlicht und/oder in einem dumps/-Verzeichnis Ihres Servers abgelegt werden.
  • SCP (or WinSCP), SFTP/FTP oder irgendein anderes Übertragungsprotokoll, mit dem Sie vertraut sind, ist verfügbar.
  • Ihr Webspace-Betreiber stellt Ihnen vielleicht sogar eine Datei-Manager-Oberfläche über Ihren Webbrowser zur Verfügung. Prüfen Sie die enthaltenen Leistungen Ihres Webhostingpaketes Ihres Hostinganbieters.

Datenbank

Die meisten wichtigen Daten des Wikis werden in der Datenbank gespeichert. Wenn das Wiki gerade offline ist, kann die Datenbank durch einfaches Kopieren der Datenbankdatei gesichert werden.

Bei Verwendung des Standard-Backends MySQL oder MariaDB kann die Datenbank in eine Skriptdatei gedumpt werden, die später dazu verwendet werden kann, die Datenbank und alle darin enthaltenen Daten von Grund auf neu zu erstellen.

MySQL

Automysqlbackup

Das Paket in Debian anzeigen:

$ apt show automysqlbackup
[...]
Description: automysqlbackup creates backup every day, week and month for all of your MySQL database, to a configured folder. There's nothing to do but to install this package, and you'll rest assured that you have a way to go back in the history of your database.
[...]

Installation des Paketes:

# apt install automysqlbackup

Alle Datenbanken werden in /var/lib/automysqlbackup/ gespeichert:

$ find /var/lib/automysqlbackup/
/var/lib/automysqlbackup/
/var/lib/automysqlbackup/weekly
/var/lib/automysqlbackup/weekly/my_wiki
/var/lib/automysqlbackup/weekly/my_wiki/my_wiki_week.18.2016-05-07_15h32m.sql.gz
/var/lib/automysqlbackup/monthly
/var/lib/automysqlbackup/daily
/var/lib/automysqlbackup/daily/my_wiki

Manuelle Sicherung (Backup):

# automysqlbackup

Datenbank wiederherstellen:

gunzip < /var/lib/automysqlbackup/weekly/my_wiki/my_wiki_week.18.2016-05-07_15h32m.sql.gz|mysql -uUSER -pPASSWORD my_wiki

Für andere Distributionen, siehe Sourceforge.

Sicherung der Datenbank mit mysqldump in der shell

Der einfachste Weg, eine Dump-Datei der Datenbank zu erstellen, die Sie sichern möchten, ist es, das Standard-MySQL-Dump-Tool mysqldump aus der Kommandozeile aufzurufen. Achten Sie bitte darauf, dass alle Parameter richtig gesetzt sind, da die Wiederherstellung ansonsten Probleme bereiten kann! Abhängig von der Datenbank-Größe kann mysqldump einige Zeit in Anspruch nehmen.

Fügen Sie zunächst die folgende Zeile in die Datei LocalSettings.php ein

$wgReadOnly = 'Dumping Database, Access will be restored shortly';

Diese Zeile kann wieder entfernt werden, sobald die Sicherung abgeschlossen ist.

Ein beispielhafter Aufruf von der Linux/UNIX Kommandozeile:

mysqldump -h hostname -u userid -p --default-character-set=charset dbname > backup.sql

Ersetze hostname, userid, charset und dbname je nach Bedarf. Alle vier befinden sich in der Datei LocalSettings.php (LSP). hostname kann unter $wgDBserver gefunden werden; standardmäßig ist es localhost. userid findet man unter $wgDBuser , charset findet man unter $wgDBTableOptions , wo es nach DEFAULT CHARSET= aufgeführt ist. Wenn charset nicht angegeben wird, benutzt mysqldump wahrscheinlich den Standardwert utf8 oder, wenn eine ältere Version von MySQL benutzt wird, latin1. Während dbname unter $wgDBname zu finden ist. Nachdem diese Zeile von der Befehlszeile aus ausgeführt wurde, fragt mysqldump nach dem Server-Passwort (das unter Handbuch:$wgDBpassword in LSP zu finden ist).

Das MySQL-Dump-Tool beispielsweise ist ein Kommandozeilenprogramm, das eine Dump-Datei mit dem Namen der Datenbank(en) erzeugen kann. Das Programmverhalten kann durch Standard-Parameter verändert werden, die das Format der Ausgabedatei z.B. durch Setzen des Zeichensatzes anpassen.

Sie können sich ansehen, welchen Zeichensatz Ihre Tabellen benutzen, wenn Sie einen MySQL-Befehl wie SHOW CREATE TABLE text verwenden. Die letzte Zeile enthält dann einen DEFAULT CHARSET-Teil.

Die Ausgabe von mysqldump kann, wie folgt, durch Kompression mit gzip verkleinert werden.

mysqldump -h hostname -u userid -p dbname | gzip > backup.sql.gz

Einige neuere Versionen von MySQL zeigen möglicherweise einen Fehler bezüglich Tablespaces und PROCESS-Rechten an. MediaWiki verwendet keine Tablespaces. Die Lösung ist, dem Befehl die Option --no-tablespaces hinzuzufügen:

mysqldump --no-tablespaces -h hostname -u userid -p dbname | gzip > backup.sql.gz

Wenn die Sicherung als XML erfolgen soll, kann der --xml Parameter verwendet werden:

mysqldump -h hostname -u userid -p --xml dbname > backup.xml

und zum Komprimieren der Datei mit einer Pipe zu gzip:

mysqldump -h hostname -u userid -p --xml dbname | gzip > backup.xml.gz

Weitere Optionen, die man für eine Sicherung mit mysqldump in Betracht ziehen sollte, sind folgende:

Weitere Mysqldump Optionen
Option Beschreibung
--default-character-set Standard-Zeichensatz festlegen
--no-tablespaces Keine CREATE LOGFILE GROUP oder CREATE TABLESPACE Anweisungen in die Ausgabe schreiben
--single-transaction Ausgeben einer BEGIN SQL-Anweisung vor dem Dumping der Daten vom Server
--triggers Auslöser für jede ausgewertete Tabelle
--routines Auslesen gespeicherter Routinen (Prozeduren und Funktionen) aus ausgewerteten Datenbanken
--events Auslesen von Events aus ausgewerteten Datenbanken
--add-drop-table DROP DATABASE-Anweisung vor jeder CREATE DATABASE-Anweisung einfügen
--create-options MySQL-spezifische Tabellenoptionen in CREATE TABLE-Anweisungen einbeziehen
--extended-insert Mehrzeilige INSERT-Syntax verwenden

Wenn man keine --single-Transaktion verwendet, sollten die Optionen --lock-tables und --add-locks genutzt werden.

Aufgrund einer unerwarteten Änderung in den MySQL-Versionen 5.7.41 und 8.0.32 im Februar 2023 erforderte die Option --single-Transaktion, dass der Backup-Benutzer über RELOAD oder FLUSH_TABLES-Berechtigungen verfügt. Das Problem wurde in den MySQL-Versionen 5.7.42 und 8.0.33 behoben. Für Details siehe MySQL Bug 109685 und Ubuntu Bug 2003866.

Bitte an die zusätzlichen Dateisystemkomponenten denken, die vom Wiki verwendet werden und bei einer Wiederherstellung benötigt werden könnten, wie Bilder, Logos, Skins und Erweiterungen.

Zeitgesteuerter Aufruf von mysqldump mittels cron

Cron ist eine zeitgesteuerte Aufgabenverarbeitung in Unix-artigen Betriebssystemen. Es ermöglicht eine periodische Ausführung von Aufgaben (Kommandos oder Shell-Skripte) zu bestimmten Zeiten.

Ein Beispielbefehl, den Sie mittel crontab aus ausführen können, könnte wie folgt aussehen:

nice -n 19 mysqldump -u $USER --password=$PASSWORD $DATABASE -c | nice -n 19 gzip -9 > ~/backup/wiki-$DATABASE-$(date '+%Y%m%d').sql.gz

Der Befehl nice -n 19 senkt die Priorität des Prozesses.

Für $USER, $PASSWORD, und $DATABASE sind die gültigen Werte einzusetzen. Das obige Kommando schreibt eine Backup-Datei mit dem Wochentag im Dateinamen. Für eine zusätzliche Sicherung der Bilddateien und Erweiterungen kann dieses Skript verwendet werden.

Warnung Warnung: Bitte nicht versuchen, ein Backup mit mysqlhotcopy anzulegen! Das von MediaWiki verwendete Tabellenformat kann damit nicht gesichert werden und der Versuch wird kommentarlos fehlschlagen.

Wenn diese Aufgabe in Cron über Cpanel hinzugefügt werden soll, muss das Sonderzeichen "%" maskiert werden.

/usr/bin/mysqldump -u $USER --password=$PASSWORD $DATABASE -c | /bin/gzip > ~/backup/wiki-$DATABASE-$(date '+\%Y\%m\%d').sql.gz

da sonst ein Fehler erscheint:

/bin/sh: -c: line 0: unexpected EOF while looking for matching `''
/bin/sh: -c: line 1: syntax error: unexpected end of file

mysqldump mit Systemd ausführen

Systemd vereinheitlicht Dienste-Konfigurationen und -Kontrolle. Timer sind systemd-Unit-Dateien, die Service-Dateien oder Ereignisse steuern. Timer können als Alternative zu Cron verwendet werden. Ein Beispiel für die systemd-Unit-Dateien und das Backup-Skript ist unten beschrieben.

wiki-backup.timer

Der folgende Timer startet den wiki-Backup-Dienst jeden Morgen um 05:10 Uhr.

$ cat /etc/systemd/system/wiki-backup.timer

[Unit]
Description=Run the backup service once a day
Documentation=...

[Timer]
OnCalendar=*-*-* 05:10:00
RandomizedDelaySec=600
Persistent=true

[Install]
WantedBy=timers.target
wiki-backup.service

Wenn der wiki-Backup-Timer ausgelöst wird, wird der Dienst aufgerufen. Dieser Dienst führt ein in /sbin gespeichertes Skript aus.

$ cat /etc/systemd/system/wiki-backup.service

[Unit]
Description=Run the backup service once a day
Documentation=...

[Service]
Type=oneshot
User=root
ExecStart=/sbin/wiki-backup
wiki-backup script
$ cat /sbin/wiki-backup

#!/usr/bin/env bash

# Systemd adds random paths at times. Take full control of PATH.
PATH=/bin:/sbin:/usr/bin:/usr/sbin
export PATH

# Read the backup password from conf or ini Failed
wiki_password=...

# Fix the wiki tables just in case. This step produces a lot of noise,
# so send stdout to /dev/null.
if MYSQL_PWD="${wiki_password}" \
   mysqlcheck my_wiki --auto-repair --user=mwuser 1>/dev/null;
then
    echo "Repair wiki database ok"
else
    echo "Failed to repair wiki database"
    echo "Continuing anyways"
fi

# Disable the connection from Apache to MySQL for the dump
if ! systemctl stop apache2.service ;
then
    echo "Failed to stop Apache service"
    echo "Continuing anyways"
fi

# Lock option choice due to MySQL change at versions 5.7.41 and 8.0.32 in
# February 2023. See https://bugs.mysql.com/bug.php?id=109685 and
# https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/2003866.
if mysql --version 2>&1 | grep -q -E 'mysql[[:space:]]+Ver 8\.0\.32'; then
   echo "Using MySQL --lock-tables --add-locks options"
   mysql_lock_opt="--lock-tables --add-locks"
else
   echo "Using MySQL --single-transaction option"
   mysql_lock_opt="--single-transaction"
fi

if MYSQL_PWD="${wiki_password}" \
   mysqldump --no-tablespaces \
     ${mysql_lock_opt} \
     --events --triggers --routines \
     --add-drop-table --create-options \
     --extended-insert \
     --default-character-set=utf8 \
     -u mwuser -h localhost my_wiki | gzip -q -v9 > /backup/wiki-backup.sql.gz ;
then
    echo "Dump wiki database ok"
else
    echo "Failed to dump wiki database"
    echo "Continuing anyways"
fi

# Re-enable connection from Apache to MySQL for the dump
if ! systemctl start apache2.service ;
then
    echo "Failed to start Apache service"
    echo "Continuing anyways"
fi

exit 0

Tabellen

Einige der gedumpten Tabellen sind unterschiedlich temporär. Um Speicherplatz zu sparen (über das einfache Gzipen hinaus), müssen diese Tabellen in einem echten Dump vorhanden sein, ihre Daten jedoch nicht. Unter bestimmten Umständen kann jedoch der Nachteil, alle diese Daten neu erstellen zu müssen, die Einsparung an Speicherplatz überwiegen (z. B. bei einem großen Wiki, bei dem die Wiederherstellungsgeschwindigkeit von größter Bedeutung ist).

Siehe Mailinglisten-Thread mysql5 binary schema' zu diesem Thema.

Latin-1 zu UTF-8 Konvertion

Siehe den relevanten Abschnitt der Erweiterungsseite für Informationen über diesen Prozess. Siehe auch die Talk-Seite für weitere Informationen über die Arbeit mit Zeichensätzen im Allgemeinen.

PostgreSQL

Mit dem Werkzeug pg_dump kann man eine MediaWiki PostgreSQL Datenbank sichern. Zum Beispiel:

pg_dump mywiki > mywikidump.sql

wird die mywiki Datenbank in mywikidump.sql ausgeben.

Wiederherstellen des Dumps:

psql mywiki -f mywikidump.sql

Möglicherweise sind globale Informationen, wie z. B. die Datenbankbenutzer, ebenfalls von Interesse:

pg_dumpall --globals > postgres_globals.sql

SQLite

Wenn dein Wiki gerade offline ist, kann seine Datenbank durch einfaches Kopieren der Datenbankdatei gesichert werden. Andernfalls solltest du ein Wartungsskript verwenden: php maintenance/SqliteMaintenance.php --backup-to <backup file name>, das sicherstellt, dass die Operation atomar abläuft und keine Inkonsistenzen existieren. Wenn deine Datenbank nicht sehr groß ist und der Server nicht stark belastet wird, werden die Benutzer, die das Wiki bearbeiten, lediglich eine kurze Verzögerung bemerken. Nutzerinnen und Nutzer, die nur lesen, werden in jedem Fall nichts bemerken.

phpMyAdmin

Stellt euer Wiki auf „nur lesen“, indem ihr $wgReadOnly = 'Site Maintenance'; in LocalSettings.php hinzufügt.

Die Wiki-Datenbank befindet sich in LocalSettings.php. Hier ein Beispiel dafür, wie dies in LocalSettings.php aussieht:

## Database settings
$wgDBtype           = "mysql";
$wgDBserver         = "localhost";
$wgDBname           = "sashtmax_mw19999";
$wgDBuser           = "sashtmax_mw19999";
$wgDBpassword       = "S7[88p]jJJ";
  1. Öffnen Sie im Browser den phpadmin-Link, melden Sie sich an und wählen Sie die Wiki-Datenbank.
  2. Export wählen Vergewissern Sie sich, dass alle Elemente unter Export ausgewählt sind, und achten Sie darauf, dass Struktur hervorgehoben ist (es ist wichtig, die Tabellenstruktur zu erhalten). Aktivieren Sie optional die Option DROP TABLE, um bestehende Referenzen beim Importieren zu löschen. Achten Sie darauf, dass Daten markiert ist.
  3. Markieren Sie gezippt.
  4. Klicken Sie auf GO und speichern Sie die Backup-Datei.[1]
  5. $wgReadOnly = 'Site Maintenance'; wieder aus der Datei LocalSettings.php entfernen

Denken Sie daran, auch die Dateisystemkomponenten des Wikis zu sichern, die möglicherweise benötigt werden, z. B. Bilder, Logos und Erweiterungen.

HeidiSQL (alternative to phpMyAdmin)

HeidiSQL ist ähnlich wie phpMyAdmin, aber ohne die Einschränkungen der kostenlosen Version von phpMyAdmin. HeidiSQL erfordert eine direkte Datenbankverbindung, während manche Hoster nur Webschnittstellen (phpMyAdmin) für mit einer Firewall geschützte Datenbanken anbieten.

Dateisystem

MediaWiki speichert andere Komponenten des Wikis im Dateisystem.

Die wichtigsten davon sind:

  • LocalSettings.php
  • hochgeladene Dateien im Verzeichnis images/ (einschließlich gelöschter Dateien, Miniaturansichten und gerenderter Mathematik- und SVG-Bilder, falls vorhanden).

Der beste Weg, diese Dateien zu sichern, liegt darin, sie in eine Archivdatei zu packen, die zum Beispiel das .tar-Format hat; eine Kompression ist bei Bedarf möglich. Unter Windows können dazu Programme wie WinZip, WinRar oder 7-Zip verwendet werden.

Bei den Linux-Varianten, falls das Wiki in /srv/www/htdocs/wiki gespeichert ist:

tar zcvhf wikidata.tgz /srv/www/htdocs/wiki

Es sollte möglich sein, den gesamten "wiki"-Ordner in "htdocs" zu sichern, falls XAMPP verwendet wird.

Konfigurationsdateien

LocalSettings.php ist das wichtigste, aber ein Wiki kann auch Dinge wie .htaccess oder andere Webserver-Konfigurationsdateien enthalten, die gesichert werden sollten.

Hochgeladene Dateien

Dateien, die in das Wiki hochgeladen wurden, befinden sich standardmäßig im Verzeichnis images/, unterteilt in Unterverzeichnisse wie images/8/8f. Außerdem gibt es weitere Verzeichnisse wie images/archive/ und images/deleted/. Sie sollten alle gesichert werden.

images/thumb/ kann zusammen mit allem anderen gesichert werden. Optional kann es aber auch ausgeschlossen werden, um Speicherplatz zu sparen. In diesem Verzeichnis werden die Vorschaubilder von Bildern und anderen Dateien gespeichert; in der Regel mehrere Vorschaubilder pro Wiki-Datei. Nach der Wiederherstellung aus dem Backup werden diese Miniaturansichten bei Bedarf neu erstellt (je nachdem, ob $wgGenerateThumbnailOnParse erforderlich ist, könnte dieser Vorgang jedoch manuell nötig werden).

Backup des Wiki-Inhalts (XML dump)

Es ist auch eine gute Idee, einen XML-Dump zusätzlich zum Datenbank-Dump zu erstellen. XML-Dumps enthalten den Inhalt des Wikis (Wiki-Seiten mit allen Versionen oder wahlweise nur der letzten Version), jedoch ohne die verwandten Daten (keine Benutzeraccounts, keine Bild-Metadaten, keine Protokolle usw.). XML-Dumps sind von der Datenbankstruktur unabhängig und können in zukünftige (und auch ältere) Versionen von MediaWiki importiert werden. Solche Dumps verursachen meistens auch weniger Probleme mit Zeichensätzen und können leicht von Drittanbieter-Tools verarbeitet werden. Dies macht sie zu einer guten Absicherung, sollte Ihr Hauptdatenbank-Dump unbrauchbar geworden sein.

XML-Dumps verursachen weniger Probleme mit der Zeichenkodierung. Sie sind ein Mittel zur schnellen Übertragung großer Mengen von Inhalten und können leicht von Drittanbieter-Tools verwendet werden, was XML-Dumps zu einem guten Ersatz für den Fall macht, dass der Hauptdatenbank-Dump unbrauchbar wird.

Um einen XML-Dump zu erstellen, benutzen Sie das Kommandozeilentool dumpBackup.php , das sich im maintenance-Verzeichnis Ihrer MediaWiki-Installation befindet. Siehe Handbuch:dumpBackup.php für Details.

Sie können auch für einen Teil der Seiten online einen XML-Dump erstellen, indem Sie die Export-Spezialseite (Special:Export) benutzen, auch wenn der Versuch, größere Textmengen oder längere Versionengeschichten mit diesem Tool zu sichern, meistens an einem Timeout scheitert.

Um einen XML-Dump in Ihr Wiki zu importieren, benutzen Sie das Kommandozeilentool importDump.php . Für wenige Seiten können Sie auch die Import-Spezialseite benutzen, welche aber normalerweise auf die sysop-Benutzergruppe beschränkt ist.

Siehe Handbuch:XML-Dumps importieren für weitere Informationen.

Ohne Shell-Verbindung zum Server

See m:Data dumps about Wikimedia database dumps.

WikiTeam3

Wenn du keinen Server-Shell-Zugang hast, verwende das Python 3 Skript des Save the Web Project WikiTeam3 (vollständige Anweisungen findest du unter diesem Link).

Windows: When using --images, because NTFS does not allow characters such as :*?"<>| in filenames, some files may not be downloaded, please check the errors.log file.
Example usage
  • --curonly dumps only the latest revision of pages
  • --xml exports an XML dump, uses Special:Export by default when no other xmldump method is specified.
  • --xmlrevisions uses API:Alle Versionen (MediaWiki 1.27+) xmldump method. Recommended as it's quicker and puts almost no pressure on the MediaWiki backend compared to Special:Export.
  • --images generates an image dump
  • --force generates a dump even if there is one already at Internet Archive
Public wikis
wikiteam3dumpgenerator <WIKI_URL> --xml --xmlrevisions
Private wikis
To dump a private wiki you will have to use a login that has at least read permission on the wiki.
wikiteam3dumpgenerator <WIKI_URL> --xml --xmlrevisions --force --user <USER> --pass <PASSWORD>
If that doesn't work. Login with a web browser, save the site cookies in Netscape format to cookies.txt, and add option --cookies cookies.txt

Skripte

With server shell access

Warnung Warnung: Die Verwendung erfolgt auf eigene Gefahr. Überprüfen Sie die LocalSettings.php Ihres Wikis, um den richtigen Zeichensatz zu verwenden, da Sie das Skript eventuell anpassen müssen.
  • Inoffizielles Backup-Skript von Flominator; erstellt ein Backup aller Dateien und der Datenbank, mit optionaler Backup-Rotation. Shell script - last updated 2012.
  • Ein weiteres Backup-Skript, das: DB, Dateien (standardmäßig nur Bilder, optional alle Dateien in der Installation) und XML auslagert; die Site in den Nur-Lese-Modus versetzt; Backups mit einem Zeitstempel versieht; und den Zeichensatz aus LocalSettings liest. Das Skript muss nicht für jede zu sichernde Website angepasst werden. Es werden (noch) keine früheren Backups rotiert. Anwendung: backup.sh -d backup/directory -w installation/directory. Enthält ebenfalls ein Skript zur Wiederherstellung einer Sicherung restore.sh -a backup/directory/dated_archive.tar.gz -w installation/directory. Das Shell-Skript wurde zuletzt 2013 aktualisiert.
  • MediaWiki Backup Script für Windows – ein Skript zum Sichern einer Windows-MediaWiki-Installation. Hinweis: Es verfügt über keine Wiederherstellungsfunktion. Das Shell-Skript wurde zuletzt 2015 aktualisiert.
  • Inoffizielles Backup-Skript von User:Duesentrieb. Das Shell-Skript wurde zuletzt 2016 aktualisiert.
  • Skript zur Erstellung regelmäßiger Backups mw_backup. Dieses Skript erstellt tägliche, wöchentliche und monatliche Backups Ihrer Datenbank und Ihres Bilderverzeichnisses, wenn es als täglicher Cron-Job ausgeführt wird. Das Shell-Skript wurde zuletzt 2017 aktualisiert.
  • in weiteres inoffizielles MediaWiki-Backup-Skript für Windows von Lanthanis, das, die Seiten der angegebenen Namespaces als XML-Datei exportiert; angegebene Datenbanktabellen auslagert; und weitere angegebene Ordner und Dateien zu einer ZIP-Backup-Datei hinzufügt. Kann mit dem Windows-Taskplaner verwendet werden. Letzte Aktualisierung 2019

Without server shell access

For example your wiki is in a wikifarm , using the MediaWiki API .

  • WikiTeam's dumpgenerator Python 2 script can generate an XML dump and an image dump - last updated 2023.
  • Mediawiki Client Tools' MediaWiki Dump Generator dumpgenerator Python 3 script can generate an XML dump and an image dump - last updated 2023.
  • See above: Save the Web Project's WikiTeam3 wikiteam3dumpgenerator Python 3 script can generate an XML dump and an image dump - actively maintained in 2024.

Erweiterungen

Siehe auch

Einzelnachweise