Archiv verlassen und diese Seite im Standarddesign anzeigen : [TIP] Scripte für Datenbank-Backup und -Restore
Supernature
12.03.2002, 09:11
Mir ist aufgefallen, dass immer wieder Probleme und Fragen zum Thema "Datenbank-Backup" auftauchen.
Ist auch nachvollziehbar, denn die wenigsten Hoster bieten Telnet- oder SSH-Zugang, und phpmyadmin ist nur bedingt zu gebrauchen.
Darum will ich mal erläutern, wie ich das mache, vielleicht hilft es ja dem Einen oder Anderen. Sollte das schon mal dagewesen sein, bitte ich um Nachsicht.
Die Scripte sind nicht von mir, ich möchte mich nicht mit fremden Federn schmücken. Voraussetzung für die Nutzung sind ein Unix-Server mit GZIP-Unterstützung (das dürfte bei 99,9% der Hoster zutreffen). mySQL-Dump muss ebenfalls vom Hoster aktiviert sein.
Und so gehts:
Zuerst auf Eurem Webspace ein Verzeichnis anlegen, in dem die Scripte abgelegt werden und per CHMOD die Rechte auf 777 setzen. Damit keiner unbefugt darauf zugreift, sollte es z.B. mit htaccess geschützt werden.
Beigefügte ZIP-Datei entpacken, dann die db_backup.php3 mit einem Texteditor öffnen und die Variablen ausfüllen, sollte eigentlich selbsterklärend sein, daher nur zwei Hinweise:
Bei "$pfad:" wird der absolute lokale Pfad auf dem Server eingetragen (ohne "/" am Ende) - wenn dieser nicht bekannt ist, die Datei root.php3 in das eben erstellte Verzeichnis laden und im Browser aufrufen.
(ansonsten wird die root.php3 nicht gebraucht).
Bei "$download_url:" wird die normale Web-Url mit "/" am Ende (ohne Dateinamen) eingetragen.
Das Ausfüllen der db_restore.php3 sollte dann kein größeres Problem mehr darstellen.
Nun werden die Dateien db_backup.php3, db_restore.php3 und error.txt in das neu erstelle Verzeichnis hochgeladen. Die Rechte der error.txt müssen noch per CHMOD auf 777 gesetzt werden.
Um die Datenbank zu sichern, muss jetzt nur noch die db_backup.php3 im Browser aufgerufen werden.
Um ein Backup wieder einzuspielen, muss die vorhandene Datei in "backup.sql.gz" umbenannt und anschliessend die db_restore.php3 im Browser aufgerufen werden.
Ich sichere meine mittlerweile 95 MB große Datenbank täglich problemlos und ohne Timeout.
Die Scripte sind sehr einfach gestrickt und geben fast immer eine Erfolgsmeldung, auch im Fehlerfall ;)
Wenn Backup oder Restore in weniger als einer Sekunde durchlaufen, dann ist wohl was schief gegangen. Um das rauszufinden, müsst Ihr ins Error-Logfile schauen, die meisten Hoster gewähren ja Zugriff darauf.
Ich hoffe geholfen zu haben ;)
firelooper
31.03.2002, 21:57
ein riesen Dankeschön an dich! das backuppen funktioniert sehr gut und auch daseinlesen mit den dateien !
firelooper
s.molinari
01.04.2002, 10:05
Hallo Supernatural,
Vielen Dank!. Solche kleine Hilferleien sind immer Willkommen.:D
Ich habe eine Kopie ins Tips und Tricks Forum verschoben und einen Link in unserer Downloadsseite hinzugefügt. Ich hoffe das geht in Ordnung.:)
Scott
firelooper
01.04.2002, 12:28
hi Scott ...
.. die scripte sind mehr als eine "kleine Hilfe" sie funktionieren einfach 1a und was ich einfach nicht verstehen kann warum so was nicht einfach mit ins vb eingebaut wird. da wird es wohl gründe geben doch zu überlegen wäre es doch mal für die 3er version. und wie man hier sieht tauchen die fragen wegen des rückschreibens immer wieder auf.
firelooper
s.molinari
01.04.2002, 13:02
Klein sind sie schon... aber mit grosse Wirkung;)
Tja... warum vB sowas nicht integriert ist eine gute Frage. Vielleicht weil sie (jelsoft) nichts drin haben wollen das die Datenbank ansich zerstören kann. Eine andere Erklärung habe ich nicht.
Scott
Wildthinks
16.04.2002, 20:12
bei puretc muß man das gzip rausnehmen, da sonst die limits greifen und das script nur müll liefert--- dump als text geht auch....
Viper888
22.04.2002, 17:12
Super - getestet - 3 mal geschwitzt ( da das backup 3 mal nur 35b kb hatte) beim 4ten mal gelacht weils ging.
Danke
Birdie501
23.04.2002, 12:47
Hi,
wollte nur kurz darauf hinweisen, dass ich mich auch nicht mit fremden Federn schmücken möchte, aber ich habe diese 2 Skripte in einen Hack vereint. Man kann damit das Backup und das Restore aus dem Admin CP erledigen.
:cool:
Wie muß ich die Scripte anpassen, damit das auch auf Win32-Systemen läuft?
Pfad zu MySQL: C:\apache\mysql\bin
Bei mir ist auch das Problem, dass er in der Zeile:
$parameter="--host=".$db_host." --user=".$db_username." --password=".$db_passwort." --database=".$db_name." <".$pfad."/backup.sql";
ab dem "<" alles abschneidet.
Supernature
25.04.2002, 09:55
@Birdie501: tolle Arbeit, das werde ich gleich einbauen!
@Boothby: Ich weiss nicht ob man das unter Windows zum Laufen bekommt - GZIP gibts soweit ich weiss nur unter Unix-Systemen.
Unter Windows arbeite ich immer mit dem "normalen" mysql-Dump-Befehl
Birdie501
25.04.2002, 13:34
Hi Leute,
ich habe mit Jens, dem Entwickler dieses Skriptes gesprochen!
Er gab mir diese Auskunft!
typische Fehler weil dieses Skript nicht läuft sind:
Kein Linux System, Mysqldump durch Hoster gesperrt,
Verzeichnis nicht auf 777. Es kann auch sein, dass ein Time- oder
Memorylimit beim Hoster erreicht wird und dadurch das Backup nicht geschrieben wird. Es gibt also sehr viel Möglichkeiten, warum es nicht läuft und speziell das sperren vom Mysqldump und der Einsatz eines Memory/Time Limit ist gerade bei Webspace Anbietern sehr beliebt. Durch
die Limits konnte ich z.B. bei Schlund und Partner kein Backup mehr machen (und musste am Vertragsende gegen eine Gebühr ein Backup erstellen lassen). Bei Puretec und Domainfactory wird es genauso ablaufen. Das Mysqldump ist - meiner Meinung nach - bei nur sehr wenigen
Webspace-Anbietern nützlich, sondern fast ausschließlich bei Usern mit ded.Servern.
> Wieso geht es eigentlich bei Windows nicht? :-)
Geht es schon :)
Man muss allerdings entweder den Pfad zu Mysqldump wissen (z.b. c:/mysql/bin/mysqldump.exe) oder der Provider muss den Pfad in die $path Variable des Systems reinnehmen. Ansonsten gilt das gleiche wie bereits oben beschrieben.
Der Dump hat wunderbar geklappt. War auf Puretec. Nun will ich die SQL-Datei (mit WinRAR bereits entpackt) bei mir local in meine MySQL DB einspielen. Über phpMyadmin funzt es nicht, da zu groß. Habe auch schon unnütze Tabellen gelöscht. Dann kommen ständig Fehlermeldungen.
Das Einspielen unter Windows ist sehr einfach.
Dazu das Backup in das mysql/bin Verzeichnis kopieren und ein Eingabeaufforderungsfenster (DOS-Fenster) in diesem Verzeichnis öffnen.
Dann gibst Du einfach mysql datenbankname < backupname ein.
@Birdie501
Vielen Dank, super Sache! Ich hab's gleich ausprobiert (Puretec) und siehe da: haut hin!
Also nochmals: danke!
matde
Asu-chan
30.04.2002, 17:11
ich versuch des auch grad, aber irgendwie check ich ab da nichts mehr:
Um die Datenbank zu sichern, muss jetzt nur noch die db_backup.php3 im Browser aufgerufen werden.
Um ein Backup wieder einzuspielen, muss die vorhandene Datei in "backup.sql.gz" umbenannt und anschliessend die db_restore.php3 im Browser aufgerufen werden.
ich ruf des db_backup.php3 im browser auf, steht da was mit download file und klick drauf. dann kommt aber ne seite das irgendso ne sql.gz datei net existiert. im ftp prog war diese datei dann im erstellten verzeichniss. soll ich die in backup.sql.gz umbenennen? oder meine backup-datei??? und soll ich meine backup datei jetzt eigentlich ins hauptverzeichnis oder in dieses erstellte verzeichnis hochladen?
Birdie501
30.04.2002, 17:24
Original geschrieben von Asu-chan
ich versuch des auch grad, aber irgendwie check ich ab da nichts mehr:
ich ruf des db_backup.php3 im browser auf, steht da was mit download file und klick drauf. dann kommt aber ne seite das irgendso ne sql.gz datei net existiert. im ftp prog war diese datei dann im erstellten verzeichniss. soll ich die in backup.sql.gz umbenennen? oder meine backup-datei??? und soll ich meine backup datei jetzt eigentlich ins hauptverzeichnis oder in dieses erstellte verzeichnis hochladen?
Hallo,
du hast wahrscheinlich bei der Download URL einen Fehler, achte auf das slash "/" am Ende.
Wenn du restoren willst, musst du in der Tat die Datei in backup.sql.gz umbenennen, sonst geht es nicht!
Grüße
Asu-chan
30.04.2002, 17:47
ja habs auch gemerkt, trotzdem danke!
Asu-chan
01.05.2002, 15:13
sorry wenn ich nochmal nerve, aber gestern konnt ich des nich zuende machen.
also ich hab die datei in backup.sql.gz umbenannt, aber wenn ich die db_restore.php3 datei im browser öffne, steht da nur das kein backup.sql.gz vorhanden ist.
in der db_restore datei hab ich beim pfad die adresse angegeben, in der die backup.sql.gz datei is und bei download-url diesselbe adresse nur eben mit / am ende.
was hab ich jetzt schon wieder falsch gemacht? :confused:
@Asu-chan
$pfad enthält nicht die URL der Backup-Datei sondern den absoluten Pfad zur Backup Datei, siehe erstes Posting:Bei "$pfad:" wird der absolute lokale Pfad auf dem Server eingetragen (ohne "/" am Ende) - wenn dieser nicht bekannt ist, die Datei root.php3 in das eben erstellte Verzeichnis laden und im Browser aufrufen. Wenn du den absoluten Pfad nicht weißt, musst du die Datei root.php3 hochladen und ausführen.
Die Download-URL musst du in der Restore Datei egtl. überhaupt nicht angeben, d.h. den Eintrag kannst du ignorieren.
Mystics
Asu-chan
01.05.2002, 20:52
ich check immer noch net was mit dem absoluten pfad gemeint is x.X in solchen sachen bin ich eben blöd x.X
also ich hab diese root.php3 datei auch schon ausgeführt, aber da steht nur:
// $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ // $$ Wenn der absolute Pfad der eigenen Homepage $$ // $$ nicht bekannt ist, kann er mit diesem kleinen $$ // $$ Script ermittelt werde $$ // $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ /usr/local/httpd/htdocs
und des sagt mir irgendwie garnichts oO''
[EDIT]
Sorry, hatte dein Posting nicht richtig gelesen ;)
/usr/local/httpd/htdocs
Das ist der absolute Pfad :)
(der Pfad in dem die root.php3 liegt )
Asu-chan
01.05.2002, 23:41
soll ich nur des eingeben oder davor noch http://servername.com/ oder sowas?
Wenn dein Backup in dem selben Verzeichnis liegt, wie deine root.php3 Datei, dann verwendest du im Restore Script das hier:
$pfad="/usr/local/httpd/htdocs";
Asu-chan
01.05.2002, 23:57
danke ^^
Asu-chan
02.05.2002, 21:45
haltet mich für blöd aber es geht immer noch nich :( ständig wenn ich die restore datei im browser starten will steht "kein backup.sql.gz vorhanden"
Asu-chan
05.05.2002, 22:00
weiß denn keiner was da noch falsch sein könnte?? ;_;
Poste doch mal den Inhalt der Restore PHP zwischen
//
# Variablen, bitte anpassen
#und
//
# ab hier bitte nichts ändern
#Das Passwort solltest du vorher rauslöschen. :)
Und die backup.sql.gz liegt ganz sicher im richtigen Verzeichnis?
Mystics
Asu-chan
05.05.2002, 22:14
//
# Variablen, bitte anpassen
#$db_host="ftp.grantspace.dns2go.com";
$db_username="musouka";
$db_passwort="******";
$db_name="musouka";
$pfad="/usr/local/httpd/htdocs";
$download_url="http://grantspace.dns2go.com/musouka/backup/";
//
# ab hier bitte nichts ändern
#und die backup.sql.gz datei is im selben verzeichnis wie die root.php3, db_restore.php3 und db_backup.php3 dateien
Asu-chan
06.05.2002, 22:41
:(
Original geschrieben von Supernature
Ich weiss nicht ob man das unter Windows zum Laufen bekommt - GZIP gibts soweit ich weiss nur unter Unix-Systemen.
Unter Windows arbeite ich immer mit dem "normalen" mysql-Dump-Befehl Hallo Leute,
ich bin einer von denen, die es vorher immer genau wissen wollen:
- Was bedeutet der Parameter -l --add-drop-table für mysqldump? Irgendwie mag ich "drop table" beim Backupen überhaupt nicht...
- Im Grunde, und das geht jetzt keineswegs gegen das geniale Script, macht das Backup nicht anderes als schon mein altes Perl-Script:
qx"/usr/bin/mysqldump --host=hostname --password=12345pass --user=username database > dumpfile.sql";
Und zusätzlich "zipped" es den dumpfile - richtig?
Letzteres funktioniert bei Schlund & Partner ( = puretec) zur Zeit bei Datenbanken bis etwa 40MB - irgendwie haben die vor einiger Zeit mit der Erhöhung der DB-Größe von 100 auf 200 MB auch die Timeout-Limits erhöht. Nicht perfekt, aber einiges funktioniert jetzt viel besser.
Für eine Beantwortung meiner beiden Fragen wäre ich echt dankbar,
danke
Markus von www.feuerwerk.net
--add-drop-table
Das sorgt dafür, dass beim Importieren des Backups evtl. schon vorhandene Tabellen mit dem gleichen Namen gelöscht werden.
Bsp:
Bevor versucht wird, die Tabelle access beim Importieren des Backups zu erstellen, wird eine evtl. vorhandene Tabelle mit dem gleichen Namen durch diese Zeile gelöscht:
DROP TABLE IF EXISTS access;
Wenn du --add-drop-table weglässt, wird auch die o.g. Zeile im Backup weggelassen.
-l
= --lock-tables
Dadurch werden alle Tabellen der Datenbank für andere Zugriffe gesperrt, d.h. während das Backup läuft, kann keine Tabelle (z.B. durch das Board) verändert werden.
>Und zusätzlich "zipped" es den dumpfile - richtig?
Ja
Weitere Erklärungen, siehe hier:
mysqldump, Dumping Table Structure and Data (http://www.mysql.com/doc/m/y/mysqldump.html)
Mystics
Asu-chan
07.05.2002, 20:28
sorry wenn ich weiter nerv, aber weiß du nich was da jetzt noch falsch sein könnte? hab ja auf der vorigen seite den db_restore.php3 text gepostet.
Eysenbeiss
06.06.2002, 00:49
//
# Variablen, bitte anpassen
#
$db_host="ftp.grantspace.dns2go.com";
$db_username="musouka";
$db_passwort="******";
$db_name="musouka";
$pfad="/usr/local/httpd/htdocs";
$download_url="http://grantspace.dns2go.com/musouka/backup/";
//
# ab hier bitte nichts ändern
#
setz mal bei dem fettgeschriebenen noch das /backup dran !
also "/usr/local/httpd/htdocs/backup", vielleicht geht es dann
So, ich habs jetzt auch mal eingebaut, aber ich bekomm immer nur ne Datei, die 0 Kb groß ist. Und dat kann schlecht sein.
Weiss jemand, woran das liegen könnte?Alle Configangaben sind richtig.
Original geschrieben von Schumi
ich bekomm immer nur ne Datei, die 0 Kb groß ist
Habe das selbe problem. Woran liegts?
mfg,
Shock
Supernature
12.09.2002, 19:09
Habt ihr keinen Zugriff auf die Server-Logfiles? Da steht normalerweise was drin. Wenn die Datei nur 0 kb hat, dann stimmen wahrscheinlich die chmod's nicht - das Backup-Verzeichnis und die error.txt müssen auf 777 gesetzt werden.
Das hier sollte weiterhelfen, jedenfalls hat es bei mir so gefunzt ;)
Suche in der db_backup.php3 nach:
$programm="mysqldump";
und ersetze es mit:
$programm="/usr/local/mysql/bin/mysqldump";
In der db_restore.php3 nach:
$programm="mysql";
ersetze es mit:
$programm="/usr/local/mysql/bin/mysql";
Geht auch mit den veränderungen nicht. Und die chmod's sind auf 777 eingestellt.
mfg,
Shock
Supernature
13.09.2002, 12:03
hm:confused:
Und es ist auch ein Unix-Server, der gzip unterstützt?
pffffff
Ich bin bei HostEurope, ka was die da laufen haben? Sowas ist auch nicht ganz meine Materie.
mfg,
Shock
Supernature
13.09.2002, 12:23
Ich war auch bei Hosteurope, da liefen die Scripte in dem Zustand wie ich sie angehängt habe über Monate hinweg einwandfrei.
Wahrscheinlich ist irgendwo ein klitzekleiner Fehler - bei der Pfadangabe, oder irgendwo ein Komma zuviel
Bei Hosteurope kannst Du über das KIS aber auch ins Error-Logfile schauen, da sollte dann ein Hinweis zu finden sein.
errorlog:
sh: /is/htdocs/338**/www.***********.de/error.txt: Permission denied
/is/htdocs/338**/www.***********.de/1031910632.sql: No such file or directory
rm: cannot remove `/is/htdocs/33843/www.***********.de/1031910632.sql': No such file or directory
[Fri Sep 13 11:50:57 2002] [error] [client 217.227.25.135] File does not exist: /is/htdocs/338**/www.***********.de/www.****.info//backup/1031910632.sql.gz
[Fri Sep 13 11:50:57 2002] [error] [client 217.227.25.135] File does not exist: /is/htdocs/338**/www.***********.de/www.****.info//errordocs/404.html
sh: /is/htdocs/33**/www.***********.de/error.txt: Permission denied
/is/htdocs/338**/www.***********.de/1031910666.sql: No such file or directory
rm: cannot remove `/is/htdocs/338**/www.***********.de/1031910666.sql': No such file or directory
Supernature
13.09.2002, 13:20
Das sieht aus, als würde das Script auf das Root-Directory Deiner Webpräsenz zugreifen wollen - oder liegt es etwa auch dort?
Check die Pfadangaben nochmal genau
Die Pfade sind alle korekt. Kommt aber nur diese 0 KB Datei raus! :(
Gibt es noch andere möglichkeiten seine DB zu sichern?
Probier's doch mal mit diesen Scripten:
dump.php<?php
system("/usr/bin/mysqldump --add-drop-table -u USERNAME -p PASSWORT -h DATENBANKSERVER DATENBANKNAME > /ABSOLUTER_PFAD_ZUM_DUMP_VERZEICHNIS/dump.sql", $fp);
if ($fp==0) echo "Daten exportiert"; else echo "Es ist ein Fehler aufgetreten";
?>import.php<?php
system("/usr/bin/mysql -u USERNAME -p PASSWORT -h DATENBANKSERVER DATENBANKNAME < /ABSOLUTER_PFAD_ZUM_DUMP_VERZEICHNIS/dump.sql", $fp);
if ($fp==0) echo "Datenbank importiert"; else echo "Es ist ein Fehler aufgetreten";
?>Mystics
Auch bei diesem Script ist die dump.sql nur 0 KB groß. :(
Ich habe jetzt eine sql Datei die größer als 0 KB ist ( mit dem Script von Supernature). Aber die Datei ist um ein vielfaches kleiner als die die Gesammtgröße der DB! Ist es normal das die Datei so "klein" ist?
mfg,
Shock
Supernature
15.09.2002, 21:04
Wenn das Script durchgelaufen ist, solltest Du eine Datei mit der Endung sql.gz erhalten - die ist dann komprimiert und deswegen erheblich kleiner als die Datenbank selbst. Wenn Du allerdings nur eine sql-Datei hast, dann ist das Script abgebrochen, bevor der Dump vollständig war (Timeout?)
Schau Dir die Datei mal an - die letzte Table muss "word" sein, sonst ist es unvollständig.
Die Endungen sind in Ordnung, scheint jetzt alles zu funktionieren!
thx
mfg,
Shock
Gandalf2003
27.02.2004, 14:23
so, ich hab das gleiche problem:(
ordner erstellt: dbbackup auf dem root chmod 777 eingestellt
dateien kopiert und den beiden files auch die rechte gegeben.
//######### Variablen, bitte anpassen ###########
$db_host="forum.gamerscommunity.info";
$db_username="charliebrown";
$db_passwort="sagichnicht";
$db_name="charliebrown";
$pfad="www/htdocs/charliebrown";
$download_url="http://forum.gamerscommunity.info/";
$dateiname=date('U'); //muss nicht geändert werden. Damit wird ein unique Dateiname erzeugt
//######### ab hier bitte nichts ändern ###########
aber leider bleibt das file 0 kb klein^^
woran kann es noch liegen?
mein provider hat mir auch bestättigt, das die vorraussetzungen dafür vorhanden wären.
Müsste das nicht so lauten?$pfad="/www/htdocs/charliebrown"; Was steht in der error.txt?
Gandalf2003
27.02.2004, 20:04
hi du,
könnte ich dich morgen mal via icq oder so ansprechen? bin gerade nicht am platz.. :(
*thomas*<3
07.03.2005, 19:26
ich kann das nicht runterladen?
Nur Lizenzinhaber können hier Anhänge herunterladen.
Hier eine kleine Anleitung, wie du dich als Lizenzinhaber ausweisen kannst:
http://www.vbulletin-germany.com/forum/showthread.php?p=22771#post22771
Mhhh Hallo warum geht der Download nicht ? Habe mich deswegen geregt!
Greetz Jan
Der Beitrag darüber sagt doch alles. Bei mir funktioniert der Download nämlich einwandfrei.
stefanomito
14.05.2006, 21:27
hallo!
komischweise läuft bei mir das skript anscheinend problemlos durch, nur wird die ausgangsdatei (.sql) nicht gelöscht. hatte jemand von euch auch schon mal dieses problem?
danke im voraus
Brig. Gen. Jack
16.05.2006, 18:49
ein echt klasse script.
lasse es per cron laufen.
aber es hat leider noch ein riesen nachteil.
sämmtliche umlaute wie "üäöß" usw. werden in komische zeichen dargestellt.
kann man dies noch irgendwie ändern, so das auch umlaute ordentlich mit abgespeichert werde ?
und dann habe ich noch einen kleinen einfall.
ich lasse das script wie schon gesagt per cron laufen.
gibt es da eine möglicheit das nach eine bestimmt zeit ältere backups gelöscht werden.
weil nach eine zeit wird es ganz schön voll in dem verzeichnis.
aber es hat leider noch ein riesen nachteil.
sämmtliche umlaute wie "üäöß" usw. werden in komische zeichen dargestellt.
kann man dies noch irgendwie ändern, so das auch umlaute ordentlich mit abgespeichert werden?Füge mal nach --add-drop-table noch das hinzu:
--default-character latin1
stefanomito
20.05.2006, 21:01
hallo!
komischweise läuft bei mir das skript anscheinend problemlos durch, nur wird die ausgangsdatei (.sql) nicht gelöscht. hatte jemand von euch auch schon mal dieses problem?
danke im voraus
habe nun herausgefunden, dass die vom skript erstellt .sql-datei nicht automatisch die rechte 777 bekommt und deshalb vermutlich nicht gelöscht werden kann. dem ordner habe ich allerdings diese recht schon gegeben. woran kann das liegen?
zudem ist die durch das skript erstellte .sql-datei um vieles kleiner als die bisherigen .sql-dateien (via mysql-front). ich habe in meinem forum zahlreiche attachements. vielleicht hat das damit etwas zu tun.
wäre für jede hilfestellung dankbar!
stefanomito
26.05.2006, 21:47
kann mir wirklich niemand helfen?
Mit welchem Modus Dateien auf einem Linux-System erstellt werden, legst du mit dem Tool umask fest. Wie umask funktioniert, wird z.B. hier (http://www.linuxforen.de/forums/showthread.php?t=188638&highlight=umask) erklärt.
Aus Sicherheitsgründen rate ich aber davon ab, MySQL-Datenbankdumps mit den Rechten 777 erstellen zu lassen, da sie damit von jedem Benutzer und Prozess lesbar und löschbar ist.
stefanomito
05.06.2006, 00:07
Mit welchem Modus Dateien auf einem Linux-System erstellt werden, legst du mit dem Tool umask fest. Wie umask funktioniert, wird z.B. hier (http://www.linuxforen.de/forums/showthread.php?t=188638&highlight=umask) erklärt.
Aus Sicherheitsgründen rate ich aber davon ab, MySQL-Datenbankdumps mit den Rechten 777 erstellen zu lassen, da sie damit von jedem Benutzer und Prozess lesbar und löschbar ist.
Hallo Tomek!
Danke für die Hilfestellung. Hab das Problem mittlerweile behofen. Ich habe auf Empfehlung im Backup-PHP-Skript den Befehl rm durch den Befehl unlink ersetzt. Jetzt funktioniert alles wie gewünscht.
Danke!
vBulletin® v3.7.2, Copyright ©2000-2008, Jelsoft Enterprises Ltd.