Ich würde gerne alle 4 Stunden perCronjob sämtliche Datenbanken des Spiels sichern. Gibt es einen SQL Befehl, der mir einen fertigen Dump ausgibt ?
So das man dann den Result nur in einer Text/Zip-Datei auf dem Serverspeichern brauch.
Oder mit welchen Funktionen/Befehlen ließe sich ein solcher Dump realisieren.
Schon mal jetzt danke für die Hilfe
Dump automatisch perCronjob
gepostet vor 19 Jahre, 4 Monate von Sellfisch
gepostet vor 19 Jahre, 4 Monate von RedMax
Ich würds mit dem Programm mysqldump versuchen
gepostet vor 19 Jahre, 4 Monate von garyx7de
#!/bin/sh
cd /srv/Backup
rm -rf datenbank.sql.gz
mysqldump --user=11111 -p11111 datenbank > datenbank.sql
gzip -9 datenbank.sql
chmod 700 datenbank.sql.gz
php -f backup.datenbank.php
cd /srv/Backup
rm -rf datenbank.sql.gz
mysqldump --user=11111 -p11111 datenbank > datenbank.sql
gzip -9 datenbank.sql
chmod 700 datenbank.sql.gz
php -f backup.datenbank.php
gepostet vor 19 Jahre, 4 Monate von neit
Und ganz wichtig: Das ganze dann noch per FTP auf nen andren Server oder Backupspace verschieben weil jedem früher oder später mal ne Festplatte abschmiert ....
gepostet vor 19 Jahre, 4 Monate von BLUESCREEN
Original von garyx7de
rm -f datenbank.sql.gz; #das r (rekursiv) macht da keinen Sinn -> also nur "-f" statt "-rf"
(...)
chmod 600 datenbank.sql.gz; #600 statt 700, oder sind deine .gz ausführbar?
Und was soll das noch? Das Backup ist doch bereits vorhanden!?
Original von garyx7de
php -f backup.datenbank.php
gepostet vor 19 Jahre, 4 Monate von garyx7de
achso die php datei schreib mir in die Datenbank das es gemacht wurde (;
so wie es dort ist passt es und es funktioniert. :wink:
ob 700 oder 600 ist doch egal (; ich kanns ja auch 777 oder 666 oder einfach 000 machen ^^
@neit: ja das sollte man auch noch wobei ich das noch nicht hinbekommen haben per SH, ich mach das immer mit einem extra programm das von Strato zur verfügung gestellt wird.
so wie es dort ist passt es und es funktioniert. :wink:
ob 700 oder 600 ist doch egal (; ich kanns ja auch 777 oder 666 oder einfach 000 machen ^^
@neit: ja das sollte man auch noch wobei ich das noch nicht hinbekommen haben per SH, ich mach das immer mit einem extra programm das von Strato zur verfügung gestellt wird.
gepostet vor 19 Jahre, 4 Monate von Kallisti
fear teh powah of scp:
http://www.micro-gravity.com/old/documents/unix-automation.html
http://www.mail-archive.com/[email protected]/msg02543.html
2 minutes of googling.. )
scp > ftp ;-)
http://www.micro-gravity.com/old/documents/unix-automation.html
http://www.mail-archive.com/[email protected]/msg02543.html
2 minutes of googling.. )
scp > ftp ;-)
gepostet vor 19 Jahre, 4 Monate von hagish
mysqldump -Q ...
"-Q" kann ich noch empfehlen, da die Tabellennamen dann in `` stehen.
"-Q" kann ich noch empfehlen, da die Tabellennamen dann in `` stehen.
gepostet vor 19 Jahre, 4 Monate von Temruk
Und dann wie erwähnt die Backups schieben. Wir machen das auf unseren Spielservern so, dass zu jeder Stunde ein Server sich sichert und seine Backups an die anderen verteilt. So hat man im Notfall schnell ein Backup zur Hand.
gepostet vor 19 Jahre, 4 Monate von garyx7de
Wie verschiebt ihr die? ich mach das mit irgend einem Programm von Strato aber wie geht das per SH?
gepostet vor 19 Jahre, 4 Monate von woodworker
per SH?
na einfach mv
wen du mit SH die shell meinst oder meinst du evtl SSH
dann schau dir scp an
na einfach mv
wen du mit SH die shell meinst oder meinst du evtl SSH
dann schau dir scp an
gepostet vor 19 Jahre, 4 Monate von Kallisti
Original von Kallisti
fear teh powah of scp:
http://www.micro-gravity.com/old/documents/unix-automation.html
http://www.mail-archive.com/[email protected]/msg02543.html
2 minutes of googling.. )
scp > ftp ;-)
Und wenn es um scp ging, die Augen aufmachen...
gepostet vor 19 Jahre, 4 Monate von mow
wieso wollt ihr den dump sichern und nicht die datenbank-dateien selbst?
diese liegen in der regelen in /var/lib/mysql/datenbankname
diese liegen in der regelen in /var/lib/mysql/datenbankname
gepostet vor 19 Jahre, 4 Monate von Crafty-Catcher
Original von mow
wieso wollt ihr den dump sichern und nicht die datenbank-dateien selbst?
diese liegen in der regelen in /var/lib/mysql/datenbankname
So wie du die Frage stellst, hast du sicher Gründe dafür warum man die Dateien sichern sollte.
Könntest du uns diese evtl. mitteilen?
(Ich sicher immer Dumps - weil ich habe keinen Root Server - mit Root Server würde ich auch weiterhin Dumps machen weil sich diese einfach besser Handeln lassen.)
Versuch z.B. mal mit den Dateien einen Fehler zu finden. Mit Dumps kann man eben schnell Werte in den Tabellen vergleichen.
Oder versuch mal nur einen Teil der Tabelle wieder herzustellen.
gepostet vor 19 Jahre, 4 Monate von Chojin
Weil ein Dump nunmal die sauberste Lösung ist. Die Datenbankdatei kannst du zum Beispiel nicht einfach auf dein Testsystem kopieren und dann davon ausgehen, dass die Datenbank die Datei einfach problemlos annimmt. Man hat Beispielsweise in einer anderen Umgebung auch andere Einstellungen bei MySQL etc.
Die Daten zu haben ist deshalb um einiges besser als die Datenbankdateien.
Reg4rds
chojin
Die Daten zu haben ist deshalb um einiges besser als die Datenbankdateien.
Reg4rds
chojin
gepostet vor 19 Jahre, 4 Monate von mow
ich bin von rootservern ausgegangen, kenne nichts anderes
die datenbanktabellen direkt zu kopieren is einfach sehr viel schneller und einfacher. wir hatten auch nie probleme mit der interoperabilität da alle server gleich (gut) konfiguriert sind
die datenbanktabellen direkt zu kopieren is einfach sehr viel schneller und einfacher. wir hatten auch nie probleme mit der interoperabilität da alle server gleich (gut) konfiguriert sind
gepostet vor 19 Jahre, 3 Monate von garyx7de
wie löscht man eigentlich allte .gz dateien die z.b. 7 tage alt sind=
gepostet vor 19 Jahre, 3 Monate von Kallisti
Original von garyx7de
wie löscht man eigentlich allte .gz dateien die z.b. 7 tage alt sind=
google logrotate
gepostet vor 19 Jahre, 3 Monate von woodworker
Kallisti logrotate löcht nix
was er sucht wäre evtl
find ./ -ctime 7 -name '*.gz' -exec rm {} \;
was er sucht wäre evtl
find ./ -ctime 7 -name '*.gz' -exec rm {} \;
gepostet vor 19 Jahre, 3 Monate von Kallisti
Original von woodworker
Kallisti logrotate löcht nix
Hmm doch? Iirc hat logrotate eine option zB genau 5 Logs zu behalten und alle aelteren zu loeschen...
So, grad geschaut:
rotate x
in /etc/logrotate.d/scriptname gibt an, wie viele Logs behalten werden...
Machst du taeglich ein backup und stellst den Wert auf 7, schon passt es...
gepostet vor 19 Jahre, 3 Monate von woodworker
aber er war eh daran intgerssiert wie man 7 tage alte .gz datein löcht und nicht wie man logs löcht
gepostet vor 19 Jahre, 3 Monate von Kallisti
Ob es logs oder dumps sind, ist doch ziemlich egal? Es sind Dateien, um deren Entstehung muss sich logrotate ja nicht kuemmern.
Und im Grunde ist ein sql dump auch eine Form von log. :-)
Und im Grunde ist ein sql dump auch eine Form von log. :-)
gepostet vor 19 Jahre, 3 Monate von felix
Steht hier auch irgendwo wie ich den Dump automatisch auf ein anderes System kopieren kann? Und wie ich den kleiner als 500 Megs kriege, also möglichst klein, ohne den ganzen Table definitions und Insert-Kram...?
gepostet vor 19 Jahre, 3 Monate von BLUESCREEN
Original von felix
Steht hier auch irgendwo wie ich den Dump automatisch auf ein anderes System kopieren kann?
Seite 1, Post 7.
Original von felix
Und wie ich den kleiner als 500 Megs kriege, also möglichst klein, ohne den ganzen Table definitions und Insert-Kram...?
Es ist der Sinn eines Dumps, die INSERTs usw. zu enthalten...
Wenns kleiner werden soll musst du es halt packen.
gepostet vor 19 Jahre, 3 Monate von Sarge
mysqldump ist für größere Datenbanken leider absolut unbrauchbar da den Dump zu erstellen viel zu lange benötigt.
--> mysqlhotcopy (Macht quasi nichts anderes als die eigentlichen Tabellendateien wie hier vorher schon vorgeschlagen wurde zu kopieren (wahlweise noch --noindices ums noch n bissl zu minimieren) nur das es automatisch dafür sorgt noch dass davor alle zu kopierende dateien gelocked werden und austehende noch nicht auf platte geschriebene sachen auf die platte geschrieben wird )
Wer einfach nur auf gut glück (ohne lock+flush) die Dateien kopiert erhält zu sehr hoher wahrscheinlichkeit ein inkonsistentes Backup.
--> -t bzw --no-create-info
--> --extended-insert
Aber die größe ist ziemlich irrelevant imho, denn jag es einfach gleich durch ne pipe an gzip
ein schnipsel aus mein altes komplett backup script:
date=`date -Ihours |head -c 13`
file=$1-sqldump-$date.sql.gz
mysqldump -u $sqluser -p$sqlpass --all --add-drop-table --extended-insert --quick --lock-tables $1 | gzip >$file
Aber wird wie gesagt sobald die Datenbank etwas größer wird viel viel zu langsam.
// edit:
reich ich noch kurz ein schnipsel um die entsprechende dateien dann auch noch woanders hinzuschieben.
Hier scheint die Mehrheit ja scp zu bevorzugen aber da viele RZ die Backupserver bereitstellen es fast ausschließlich FTP's sind (und es damals einer war als ich es geschrieben hatte) und mir zum filetransfer auch ftp lieber ist irgendwie hier für ftp (da scheinbar viele leute probleme haben ftp im cronjob zu verwenden)
versteht sich eigtl von selbst:
open $ftphost
quote USER $ftpuser
quote PASS $ftppass
binary
cd $ftppath
put $file
quit
END_SCRIPT
--> mysqlhotcopy (Macht quasi nichts anderes als die eigentlichen Tabellendateien wie hier vorher schon vorgeschlagen wurde zu kopieren (wahlweise noch --noindices ums noch n bissl zu minimieren) nur das es automatisch dafür sorgt noch dass davor alle zu kopierende dateien gelocked werden und austehende noch nicht auf platte geschriebene sachen auf die platte geschrieben wird )
Wer einfach nur auf gut glück (ohne lock+flush) die Dateien kopiert erhält zu sehr hoher wahrscheinlichkeit ein inkonsistentes Backup.
Und wie ich den kleiner als 500 Megs kriege, also möglichst klein, ohne den ganzen Table definitions und Insert-Kram...?
--> -t bzw --no-create-info
--> --extended-insert
Aber die größe ist ziemlich irrelevant imho, denn jag es einfach gleich durch ne pipe an gzip
ein schnipsel aus mein altes komplett backup script:
date=`date -Ihours |head -c 13`
file=$1-sqldump-$date.sql.gz
mysqldump -u $sqluser -p$sqlpass --all --add-drop-table --extended-insert --quick --lock-tables $1 | gzip >$file
Aber wird wie gesagt sobald die Datenbank etwas größer wird viel viel zu langsam.
// edit:
reich ich noch kurz ein schnipsel um die entsprechende dateien dann auch noch woanders hinzuschieben.
Hier scheint die Mehrheit ja scp zu bevorzugen aber da viele RZ die Backupserver bereitstellen es fast ausschließlich FTP's sind (und es damals einer war als ich es geschrieben hatte) und mir zum filetransfer auch ftp lieber ist irgendwie hier für ftp (da scheinbar viele leute probleme haben ftp im cronjob zu verwenden)
versteht sich eigtl von selbst:
ftp -n <
open $ftphost
quote USER $ftpuser
quote PASS $ftppass
binary
cd $ftppath
put $file
quit
END_SCRIPT
gepostet vor 19 Jahre, 3 Monate von The_Alien
Man kann sich das rotieren der Backups etc auch einfach machen indem man den Wochentag dabei packt.
Das Script sicher die Servereinstellungen,die Homedirs und die Datenbank einmal am Tag und einmal im Monat nochmal extra und lädt das dann per ftp auf den Backupspace hoch (bei mir nicht mehr nötig da ich den Backupspace gemauntet habe)
Und das dann halt in ein cronjob.
MYUSER=*sqlrootuser*
MYPASS=*sqlpass*
FUSER=*ftpuser
FPASS=*ftppass*
BACKDIR=backup
mkdir -p /backup/mysql
WOTAG=`date +%a`
MONAT=`date +%e`
MO=`date +%b`
echo Dateien kopieren
rsync -az --delete --delete-after *homedir* /$BACKDIR
echo Konfiguration kopieren
rsync -az --delete --delete-after /etc /$BACKDIR
cd /$BACKDIR/mysql
echo Datenbank kopieren
mysqldump -AaCceQ -u$MYUSER -p$MYPASS -r mysql.dbs
cd /$BACKDIR
echo Einstellungen packen
if [ $MONAT -eq 1 ]; then
WOTAG = `date +%B`
fi
tar cjf etc_dirs.$WOTAG.tar.bz2 etc
echo Dateien packen
tar cjf homedirs.$WOTAG.tar.bz2 home
echo Datenbank packen
tar cjf mysqldbs.$WOTAG.tar.bz2 mysql
#echo Hochladen
#ftp -u *ftpdir* *$WOTAG*
echo Fertig
Die *...* entsprechend ersetzen. Man kann sich auch die Intervalle anpassen auf stunden etc - je nach belieben.
@Sarge - was verstehst du unter "größeren" Datenbanken?
Das Script sicher die Servereinstellungen,die Homedirs und die Datenbank einmal am Tag und einmal im Monat nochmal extra und lädt das dann per ftp auf den Backupspace hoch (bei mir nicht mehr nötig da ich den Backupspace gemauntet habe)
Und das dann halt in ein cronjob.
#!/bin/bash
MYUSER=*sqlrootuser*
MYPASS=*sqlpass*
FUSER=*ftpuser
FPASS=*ftppass*
BACKDIR=backup
mkdir -p /backup/mysql
WOTAG=`date +%a`
MONAT=`date +%e`
MO=`date +%b`
echo Dateien kopieren
rsync -az --delete --delete-after *homedir* /$BACKDIR
echo Konfiguration kopieren
rsync -az --delete --delete-after /etc /$BACKDIR
cd /$BACKDIR/mysql
echo Datenbank kopieren
mysqldump -AaCceQ -u$MYUSER -p$MYPASS -r mysql.dbs
cd /$BACKDIR
echo Einstellungen packen
if [ $MONAT -eq 1 ]; then
WOTAG = `date +%B`
fi
tar cjf etc_dirs.$WOTAG.tar.bz2 etc
echo Dateien packen
tar cjf homedirs.$WOTAG.tar.bz2 home
echo Datenbank packen
tar cjf mysqldbs.$WOTAG.tar.bz2 mysql
#echo Hochladen
#ftp -u *ftpdir* *$WOTAG*
echo Fertig
Die *...* entsprechend ersetzen. Man kann sich auch die Intervalle anpassen auf stunden etc - je nach belieben.
@Sarge - was verstehst du unter "größeren" Datenbanken?
gepostet vor 19 Jahre, 3 Monate von Sarge
schon wenn die datenbank in die 100er mb geht ist mysqldump zu langsam für mich, >1 GB unerträglich so zumindest meine erfahrung
gepostet vor 19 Jahre, 3 Monate von Kallisti
Also ein 80mb dump dauert bei mir weniger als 10 Sekunden, wie schnell soll das denn bei dir sein??
gepostet vor 19 Jahre, 3 Monate von Sarge
hmh 80mb=10sec -> 1,6gig = 200sec ~ 4min und nach meiner Erfahrung her war es wesentlich näher an nem 2 stelligem minuten bereich...
wie gesagt ich kann für größere datenbanken nur mysqlhotcopy empfehlen.. insbesondere da wenn mans auf 2 unterschiedliche platten kopiert mysqlhotcopy nocheinmal enormen geschwindigkeitsgewinn haben müsste. Leider sind unsere alten nur mit 1x ide platte ausgerüstet.
wie gesagt ich kann für größere datenbanken nur mysqlhotcopy empfehlen.. insbesondere da wenn mans auf 2 unterschiedliche platten kopiert mysqlhotcopy nocheinmal enormen geschwindigkeitsgewinn haben müsste. Leider sind unsere alten nur mit 1x ide platte ausgerüstet.
gepostet vor 19 Jahre, 3 Monate von Kallisti
Wenn man 1,6 gig DB hat und kein 10k+ aktive User Forum hostet, sollte man sich vielleicht fragen, ob man was andres falsch gemacht hat? ^^
gepostet vor 19 Jahre, 3 Monate von Sarge
aha dumm von der Seite angemacht zu werden ist hier scheinbar der Dank für den Versuch ein wenig Erfahrung weiterzugeben.
Um genau zu sein sind es nicht 10k sondern 18,xk reg. Benutzer.
Was hier das ganze mit Foren hosten zu tuen hat? :confused:
und die haben nunmal schon ein paar Nachrichten ( > 1 Mio)&Kampfberichte produziert.
Ich zwinge euch sicherlich nicht meine Tipps zu befolgen.
Um genau zu sein sind es nicht 10k sondern 18,xk reg. Benutzer.
Was hier das ganze mit Foren hosten zu tuen hat? :confused:
und die haben nunmal schon ein paar Nachrichten ( > 1 Mio)&Kampfberichte produziert.
Ich zwinge euch sicherlich nicht meine Tipps zu befolgen.
gepostet vor 19 Jahre, 3 Monate von Kallisti
Och, ich fand das Posting eigentlich ganz freundlich :-) Da war auch ein Smilie am Ende.
Forum, weil ein Forum generell sehr viel Speicher schluckt und da gigabyte Datenbanken keine Seltenheit sind, ist ja alles unique Text.
Es war nicht als "dumme Anmache" gemeint, nur wunderte ich mich ueber den hohen Verbrauch, denn bei einem Browsergame laesst der sich doch recht gut optimieren - auch bei Kampfberichten (wobei das zB bei uns auch nicht der Fall ist).
Forum, weil ein Forum generell sehr viel Speicher schluckt und da gigabyte Datenbanken keine Seltenheit sind, ist ja alles unique Text.
Es war nicht als "dumme Anmache" gemeint, nur wunderte ich mich ueber den hohen Verbrauch, denn bei einem Browsergame laesst der sich doch recht gut optimieren - auch bei Kampfberichten (wobei das zB bei uns auch nicht der Fall ist).
gepostet vor 18 Jahre, 8 Monate von garyx7de
Wie kann ich die dateien automatisch wieder vom FTP löschen. Ist mir gerade aufgefallen das ich das nie gemacht hab
local:
ftp?
bzw ncftp ?
local:
find /srv/www/htdocs/web0/sql_backup -name "*.gz" -atime 10 -exec rm -e {} \; ftp?
bzw ncftp ?