Bis Magento 1.6 unterstützt Magento das Erstellen von Datenbank-Backups über das Backend. Will man jedoch die Datenbank wieder einspielen oder den Quellcode sichern, dann ist das bisher nicht über die Administrationsoberfläche möglich. Hier greift eine weitere Neuerung in der kommenden Version Magento CE 1.7: das Erstellen von Sicherungen der Datenbank und des Dateisystems (Backup) sowie das Wiedereinspielen der Daten (Rollback).
Backups in Magento 1.6
Rufen wir uns zuerst in Erinnerung, wie die Backup-Funktionalität bis inklusive Magento 1.6 aussieht:
Ein Klick auf „Create Backup“ erstellt eine komprimierte SQL-Datei. Sie kann bei Bedarf über die Kommandozeile oder andere Tools wieder eingespielt werden.
Backups und Rollbacks in Magento 1.7
In Magento 1.7 wird dieses Feature ausgebaut. Man erreicht die Funktion wie bisher über das Navigationsmenü unter dem Punkt „System“ > „Tools“ > „Backups“. Ein Screenshot verrät einige Neuerungen:
Anstelle eines simplen „Create Backup“-Buttons sind drei unterschiedliche Sicherungen möglich:
- System Backup: dieses Backup sichert (fast) alle Dateien der Magento-Installation. Wir kommen gleich zu den Details.
- Database and Media Backup: in dieser Datei werden Inhalte des Ordners „media“ und ein Datenbank-Backup vorgehalten.
- Database Backup: hier wird wie gewohnt ausschließlich die Datenbank gesichert.
Über die Tabellenspalte „Action“ kann ein Rollback durchgeführt, die Sicherung also wieder in das System eingespielt werden. Das Löschen von Backups ist über das Actions-Dropdown weiterhin möglich.
System-Backup
Klickt man auf den Button „System Backup“, wird eine Warnmeldung angezeigt:
Wie man sich gut vorstellen kann, dauert es mitunter lange Zeit, ein vollständiges System zu sichern. Daher muss diese Operation explizit bestätigt werden. Zugleich hat man die Möglichkeit, den Shop in der Zwischenzeit in den Wartungsmodus zu versetzen.
In meinem virtuellen Testsystem benötigte das Backup eines frisch installierten Shops 45 Sekunden. Man erhält eine tgz-Datei im Verzeichnis var/backups. Die Datei wird mit einem Timestamp versehen. Sie heißt z.B. snapshot-20111231101644.tgz
Gesichert wird im Prinzip die komplette Magento-Installation ausgehend vom Magento-Root-Verzeichnis. Einige Dateien und Verzeichnisse sind davon ausgenommen:
- .svn
- maintenance.flag
- var/cache
- var/full_page_cache
- var/locks
- var/log
- var/report
- var/session
Diese Liste wird in Mage_Backup_Helper_Data::getBackupIgnorePaths() definiert. Zusätzlich zu den „normalen“ Dateien wird ein Datenbank-Backup erzeugt und in var/ abgelegt. Nach dem Backup wird der DB-Dump wieder gelöscht.
Datenbank- und Media-Backup
Vor der Ausführung des „Database and Media Backup“ erscheint dieselbe Warnmeldung wie beim System-Backup. Zumindest in einem leeren System geht diese Operation allerdings natürlich schneller von der Hand. Im Testsystem war nach 7 Sekunden alles erledigt.
Hier werden ausschließlich die Verzeichnisse media/ und var/ in eine tgz-Datei gepackt. Der Dateiname ist wiederum mit dem Zeitpunkt der Sicherung versehen, z.B. media-20111231101820.tgz.
In media/ befinden sich die Files aus der Magento-Installation inklusive der catalog/product/cache-Dateien. Das var-Verzeichnis enthält den komprimierten Datenbankexport im SQL-Format.
Datenbank-Backup
Hierzu gibt es nicht viel zu sagen. Das von Magento erstellte .gz-Archiv (Dateiname z.B. db-20111231101839.sql.gz) enthält einen SQL-Dump-File.
Rollbacks (Wiedereinspielen von Backups)
Will man einen alten Stand wiederherstellen, so öffnet sich nach dem Klick auf den Rollback-Link folgendes Warnfenster:
Diese Meldung erscheint (zumindest in der Alpha 1) unabhängig davon, welche Art von Backup eingespielt wird. Hat man bestätigt, dass man fortfahren will, muss man zur Sicherheit das Passwort des Admin-Accounts eingeben:
Diese Maßnahme ist sinnvoll, damit kein Unbefugter Unsinn anstellen kann, wenn er durch Zufall gerade an einem PC mit angemeldetem Admin-User vorbei kommt. Außerdem kann man sich noch einmal überlegen, ob man das Rollback durchführen will.
Auch hier kann der Shop in den Wartungsmodus versetzt werden. Zusätzlich kann festgelegt werden, ob man zum Einspielen des Backups eine FTP-Verbindung verwenden will. Das ist unter Umständen wegen der Größe des Backups oder der Dateirechte nötig (schließlich muss der Linux-User das Recht haben, die Dateien und Verzeichnisse zu löschen/schreiben).
Führt man ein Rollback mittels eines System-Backups durch, sind auch beim Rollback einige Dateien und Verzeichnisse ausgenommen:
- .svn
- maintenance.flag
- /index.php
- /app/Mage.php
- /errors
- /var/locks
- /var/log
- /var/report
- /var/session
Diese Liste wird in Mage_Backup_Helper_Data::getRollbackIgnorePaths() definiert. Wie gleich auffällt, bestehen Unterschiede zu den beim Backup ignorierten Dateien. Meinem Gefühl nach ist das nicht besonders sinnvoll – vielleicht kann das jemand von euch in den Kommentaren logisch erklären. 😉
Nach dem Einspielen der Dateien wird die Datenbank ebenfalls zurück gespielt. Ist der Vorgang abgeschlossen (bei mir ging es erfreulich schnell und dauerte ca. 30 bis 40 Sekunden), dann wird man zum Admin-Login-Formular zurück geleitet und kann wieder auf das alte System zugreifen. Neuere Backups dürften übrigens bestehenbleiben, was recht praktisch sein kann.
Fazit
Mit dem Ausbau der Backup- und Rollbackfunktionalität bietet Magento CE 1.7.0.0 vor allem für jene Shopbetreiber eine sehr nützliche Funktionalität, die ihren Shop nicht innerhalb eines größer angelegten Backup-/Deployment-/Rollback-Plans betreiben. Das trifft ohne Zweifel auf viele Händler zu. Magento hilft dieser Zielgruppe somit sehr, regelmäßig die Daten zu sichern und die Risiken beim Testen von Änderungen im Shop zu reduzieren.
Hallo,
ich betreibe einen Onlineshop auf Magento 1.7.0.2 und wollte nun wie beschrieben ein BackUp vom System ziehen. System Backup lässt sich starten und es erscheint auch kurze Zeit die Wartescheibe, die sich aber dann aufeinmal wieder schließt aber es wird mir kein BackUp angezeigt.
Liegt bei mir auch das Problem des zu geringen Speicherplatzes vor oder kann es weitere Ursachen haben?
Hallo,
es kann auch andere Ursachen haben. Nachdem ich die Backupfunktionalität nicht einsetze, kann ich dazu aber keine typischen Faktoren nennen.
Hallo,
erstmal vielen Dank für die tolle Beschreibungen. Ich habe Magento 1.7 installiert. Die Sicherung der Datenbank funktioniert. Die Sicherung von „System“ bzw. von „Datenbank und Medienordner“ läuft aber praktisch ins Leere. Nach einer kurzen Weile bricht die Sicherung einfach ohne Fehlermeldung ab. Hat jemand einen Rat für mich?
Tausend Dank.
Nochmals Hallo,
danke für den Hinweis. Ich konnte den Fehler beheben. der Pfad zur Datenbank in der local.xml war leider nicht vollständig von mir eingegeben worden.
Nun aber zu einem neuen Problem. Nachdem ich auf den neuen Server umgezogen bin funktionierte soweit alles einwandfrei – dachte ich. Das Backend funktioniert vollständig und die Startseite funktioniert. Sobald ich aber im Frontend auf einen Link klicke (egal ob Artikel oder AGB, usw.) erscheint immer „Internal Server Error“. Wenn ich nun aber im Backend die Webserver Rewrites deaktiviere funktioniert die Seite einwandfrei.
Haben Sie einen Tipp für mich was ich machen muss um doch die Webserver Rewrites wieder nutzen zu können?
Danke und Gruß
Oliver
Hallo Herr Zeis,
ich hoffe Sie können mir helfen.
Ich habe vor rund 4 Monaten damit begonnen ein Magento 1.7.0.2 Shop auf zu setzen. Gehostet war der Shop bei Strato. In den letzten 4 Monaten, in denen ich den Shop offline hatte und eingerichtet habe, funktionierte alles prima. Am vergangenen Montag habe ich dann den Shop online geschalten und seit Mittwoch mittag ist er nun nicht mehr erreichbar wegen einen internen Serverfehlers. Seitens Strato tut man leider auch nichts. Daher habe ich mir nun einen neuen Provider gesucht und bin mit meinem Shop umgezogen. Nun habe ich aber ein paaar Probleme und hoffe auf Ihre kompetente Hilfe.
Was ich bisher gemacht habe:
1.) Ich habe die Datenbank bei Strato gesichert und beim neuen Provider hochgeladen.
2.) Ich habe die Shopdateien gesichert und beim neuen Provider hochgeladen.
3.) Ich habe die local.xml angepasst
4.) Ich habe in der Datenbank in der Tabelle core_config_data die secure und unsecure geändert
5.) Ich habe alles aus dem Ordner var/cache gelöscht
6.) Ich habe alles aus dem Ordner includes/src gelöscht
Nun bin ich einen Schritt weiter als bei Strato, erhalte aber eine Fehlermeldung mit dem Hinweis:“Exception printing is disabled by default for security reasons.“
Ich hoffe Sie können mir helfen.
Danke und Gruß
Oliver
Hallo,
auf dieser Seite sehen Sie auch einen Zahlencode. Im Verzeichnis var/report/ gibt es eine Datei mit dem entsprechenden Dateinamen. Dort finden Sie Informationen zum Fehler, mit denen Sie weiter recherchieren können.
Beste Grüße
Matthias Zeis
Hi Matthias,
Hast du schon einmal eine upgrade eines Magento Shop von Version 1.6.1 auf Version 1.8 gemacht?
Ich das aufwendig?
Was ist dabei zu beachten?
Danke für deine Unterstützung.
Gruss Peter
Hi Peter,
das passt nicht ganz zum Thema, aber gut. 😉 Ich habe Shops von 1.6 auf 1.7 upgedatet und von EE 1.12 auf 1.13. Das lief ziemlich gut. Der Aufwand hängt aber immer davon ab, was alles angepasst wurde und wie das gemacht wurde.
Je mehr nach den Best Practices vorgegangen wurde (Observer statt Rewrites, eigene Layout-XML-Dateien statt Kopien der vorhandenen Dateien anlegen, Template-Files nur wo nötig kopieren und anpassen, …), desto geringer der Aufwand.
Gute Tipps, worauf man achten muss, gibt es hier: How do you give estimates for Magento upgrade?
okay – sorry, hatte eine Panikattacke – index.php Rechte geändert. Jetzt funktionierts wieder.
Hallo! HIIIILLLFFEE! Ich habe das Knöpfchen System Backup bei meinem Magento 1.8. gedrückt und habe jetzt einen Internal Server Error. Bitte um Hilfe – ich weiß nicht, was ich jetzt machen muss!!! Danke!
Hallo,
habe ein Backup durchgeführt und nun sind alle meine CMS Blöcke, der komplette Footer-Bereich und der ganze Mittelteil des Magento Themes verschwunden. Das einzige was geblieben ist, ist der Header, der EM Slider und die linke Navigation. Wie komme ich an meine Daten ran?
Gruß
Hallo,
da ich die eingebaute Backup-Funktionalität nicht verwende, kenne ich das Problem nicht, aber diese Links könnten helfen:
– Backup did not save CMS pages
– Magento – CMS Daten verloren aber noch Datenbank Backup
Das Problem hatte ich auch schon mehrmals,
und es lag sehr nahe, wenigstenst in einem Fall, dass der Speicher nicht ausreiche,
weil beim Komprimieren sehr viel Speicherplatz temporär benötigt wird.
Es wurde dann nur unvollständig gepackt.
Gruß
Petra
So, da bin ich mal wieder 🙂
Obwohl vorher alles gut funktionierte, hab ich nun seit den letzten Updates das gleiche bzw. ähnliche Problem wir Mr. Brain:
Wenn ich das System-Backup (inkl medien-ordner) starte läuft für kurze Zeit (ca. ne Minute) das „bitte warten“-Schildchen, welches dann allerdings verschwindet und keinerlei Meldung erscheint. Wenn ich die Backup-Seite refreshe, erscheint zwar doch die Datei, aber die ist um einiges zu klein geraten. Die früheren Backups lagen bei 41MB und nachdem ich das jetzt habe 3 mal laufenlassen bekomme ich Dateien unterschiedlicher Größe, mit 4.1MB, 3.5MB und 3.9MB
Das sichern ohne Medien-Ordner führt zum gleichen Ergebnis. Die Datenbanksicherung hingegen funktioniert einwandfrei.
Hab auch mal in die Log-Dateien geschaut, aber dort erscheint gar nichts in dem Zeitraum.
Hast Du eine Idee, wonach ich schauen könnte?
Wenn „Loading“- oder „Please Wait“-Meldungen wortlos verschwinden, etwas scheinbar nicht funktioniert hat und man in den Log-Dateien nichts findet, kann man mit der Network-Debugging-Funktion der Firefox-Extension Firebug oder einem ähnlichen Tool weiter forschen.
Die Vorgangsweise, wenn man Firebug installiert hat: Firebug öffnen, den Network-Tab auswählen, dann im Magento-Backend die Aktion (z.B. das Backup) starten und überprüfen, ob in der „Response“ des Requests eine Meldung zu finden ist.
Hallo also ich bekomme 2 >Zeilen als Fehler. Ich vermute es hat etwas mit den Shop Sprachen zu tun.
2013-05-28T12:07:05+00:00 DEBUG (7): SQLSTATE[42S02]: Base table or view not found: 1146 Table ‚db00051454.catalog_category_flat_store_2‘ doesn’t exist
2013-05-28T12:07:05+00:00 ERR (3): User Error: Some transactions have not been committed or rolled back in /xx/xxx/xxx/home/htdocs/xxxxxxxxxxxxxxxxx.de/includes/src/__default.php on line 57792
Für die Meldung muss man sich leider näher mit dem System beschäftigen. Die Meldung lässt darauf schließen, dass die Index-Daten nicht auf dem aktuellen Stand sind bzw. die letzte Indizierung nicht vollständig durchgeführt wurde. Ich würde alle Indizes neu aufbauen.
Bei mir kommt die Fehlermeldung nachdem ich versuche einer der Backup-buttons zu drücken:
Beim Anlegen der Sicherung ist ein Fehler aufgetreten.
Nach einem reload der Seite erscheint auch meine zip datei im Backend vom Magento.
Die Zip Datei ist auch im FTP verzeichniss angelegt, aber die Datei ist unvollständig und ziemlich klein. Statt 8MB als gezippt zu sein, ist sie nur 0,05 MB groß.
Ein kleiner Tipp wäre super… Danke
Gibt es eine Meldung in einer der Log-Dateien (system.log / exception.log) oder im Exception-Report-Verzeichnis (var/report)? Siehe Hilfe, in Magento funktioniert [Feature] nicht – was kann ich tun?
Hallo,
also im DUMP steht
DROP TABLE IF EXISTS `admin_user`;
CREATE TABLE `admin_user` (
`user_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT ‚User ID‘,
…
PRIMARY KEY (`user_id`),
UNIQUE KEY `UNQ_ADMIN_USER_USERNAME` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COMMENT=’Admin User Table‘;
Auto_INCREMENT auf 2, damit vermute ich
LOCK TABLES `admin_user` WRITE;
/*!40000 ALTER TABLE `admin_user` DISABLE KEYS */;
INSERT INTO `admin_user` VALUES (‚1‘, ‚D… )
es steht auch
INSERT INTO `admin_role` VALUES
(‚1′,’0′,1,1,’G‘,’0′,’Administrators‘),(‚2′,’1′,2,0,’U‘,’1′,’D…‘);
drin.
Nach dem Wiederherstellen der DB BACKEND geschlossen –
„Ausgesperrt “ !!! “ Ungültiger Benutzername oder Passwort. “
Einloggen nicht mehr möglich – die admin_rule Tabelle ist in Ordnung
die admin_user ist leer und AUTO_INCREMENT steht auf 1.
Den admin_user kann ich problemlos wieder einfügen
( INSERT INTO `admin_user` VALUES (‚1‘, … )
und mich dann wieder einloggen.
Ich habe nun einen zweiten Admin angelegt,
nach der Rücksicherung ist die Tabelle admin_user leer.
Zur Lokalen Instalation noch folgende Daten:
WAMP 2.1
Server: localhost (localhost via TCP/IP)
Server Version: 5.5.8-log
Protokoll-Version: 10
Benutzer: root@localhost
Apache/2.2.17 (Win32) PHP/5.3.5
MySQL-Client-Version: mysqlnd 5.0.7-dev – 091210 – $Revision: 304625 $
PHP Erweiterung: mysqli
Ich habe keine Idee, traue mich gar nicht an das Produktivsystem :-).
Danke für jeden Tipp
Petra Klapproth
Darum sind wir auch nicht zu beneiden 😉
Es kann natürlich an den Autoinkremens liegen, da der Admin dann mit 2 angelegt werden „soll“
DROP TABLE IF EXISTS `admin_user`;
CREATE TABLE `admin_user` (
`user_id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT ‚User ID‘,
`firstname` varchar(32) DEFAULT NULL COMMENT ‚User First Name‘,
`lastname` varchar(32) DEFAULT NULL COMMENT ‚User Last Name‘,
…
Date‘,
PRIMARY KEY (`user_id`),
UNIQUE KEY `UNQ_ADMIN_USER_USERNAME` (`username`)
)
ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COMMENT=’Admin User Table‘;
LOCK TABLES `admin_user` WRITE;
/*!40000 ALTER TABLE `admin_user` DISABLE KEYS */;
INSERT INTO `admin_user` VALUES (‚1′,’D …
Im SQL-Script sind alle SET-Statements auskommentiert, so auch
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE=’NO_AUTO_VALUE_ON_ZERO‘ */;
bzw. man muss es für Rücksicherungen ausschalten , was man jedoch innerhab des Backendes nicht
machen kann
Andererseits hatte es schon einmal funktioniert
Petra
Der Auto-Increment-Wert sollte nicht schuld sein. Der erste Eintrag wird richtig mit Id 1 eingefügt, der Auto-Increment-Wert bleibt bei 2. Fügt man einen weiteren Eintrag ein, erhöht sich Auto-Increment auf 3.
Die Kommentare führen nur dazu, dass sie ausschließlich von MySQL ausgeführt werden. mysqldump und co. erzeugen damit ANSI-Standard-kompatible Datenbank-Dumps. Auch das sollte eigentlich in Ordnung sein.
Doofe Frage, aber: stehen wirklich alle gewünschten Admin-User im Dump? Wenn ja, gibt es keine Fehlermeldung, wenn man den Dump über den mysql-Befehl einspielt? Was passiert, wenn man die Befehle für diese Tabelle manuell ausführt?
Hallo
magento 1.7.0.2 als lokale Installation.
Folgendes Problem, wenn ich eine Datenbanksicherung aus dem Backend
zurückladen / wiederherstellen möchte – auch als Test vor der Produktivschaltung –
wird das backenend geschlossen und dann bin ich ausgesperrt.
In der admin_user Tabelle ist der Admin geloescht.
– ob mit oder one Maintanance-flag setzen
– auch wenn ich die auskommentierten SET Befehle vorher am myphp-sql absende.
Die Sicherung selbst ist nicht zurückgeladen.
Woran kann das liegen? Kennt jemand das Problem?
Ich habe noch nicht im Forum recherchiert .
Vielen Dank vorab
Petra
Hallo, diesen Effekt habe ich leider noch nicht gehabt.
Hallo,
neuer Tag neues Problem. Hab einen neuen Shop auf einem neuen Server installiert. Nun dachte ich, und das war offensichtlich total falsch, dass ich einfach das Backup vom Testserver rüberschiebe und ein Rollback mache auf den jungfräulichen Shop.
Naja funktioniert gar nicht, weil ich jetzt keine Files in den Ordnern habe bzw. auch nur mehr das Skelett da ist.
Bin Neuling in Sachen Magento, aber jetzt WILL ich das Ding fliegen könne.
Hast du eine Ahnung warum das nicht funkt.
Hallo, ganz ehrlich: wird verwenden diese Backup-Funktionalität nicht, weil wir dafür unsere eigenen Methoden haben.
Wenn man die Backup-Datei direkt am eigenen PC öffnet, sind die Dateien dann vorhanden? Falls ja, könnte es sich um ein Rechteproblem handeln.
vielen Dank für die Tipps, ich werde den Compiler wenn möglich vermeiden, es gibt auf dem System einen aktiven Varnish Cache, auch wenn dies wie es scheint kein Byte Code Cache ist
Die Funktion disk_free_space zeigt den gesamten verfügbaren Speicherplatz der Platte, nicht meines Pakets an, deswegen wurde diese Funktion wohl deaktiviert.
Eine Frage habe ich noch, bei einem Backup im Backup werden immer alle Datei- und Verzeichnisrechte korrigiert. Dateirechte haben dann den Wert CHMOD 666, was in der Umgebung zu hoch ist. Hier sollte CHMOD 644 belassen werden. Kann der Wert irgendwo korrigiert werden?
Für den Magento Connect Manager kann der Wert ja im Bereich Settings gesetzt werden. Für das Backup hat dies jedoch keinen Einfluss.
dankeschön nochmal
Varnish speichert den HTML-Code, der vom Webserver generiert wird und liefert dem nächsten Besucher mit denselben Anfrage-Parametern den HTML-Code direkt zurück, ohne den Webserver bzw. Magento überhaupt in Anspruch zu nehmen. PHP spielt da noch gar nicht mit, es ist also kein Byte Code Cache.
Mir wäre nicht bekannt, dass man die Rechte über das Backend konfigurieren kann…
Ich habe das Problem eingrenzen können. Es entsteht, wenn Magento kompiliert wird. In dem Fall werden Dateien aus dem Ordner /includes/src gezogen.
Gibt es ein Flag in der Datenbank wo festgelegt werden kann, dass die Compiler Daten nicht mehr abgefragt werden sollen? Das Deaktivieren der Compiler Funktion über das Backend bringt eine Fehlermeldung und der Shop wird nicht mehr aufrufbar.
vielen Dank für einen Tipp
Der Compiler wird verwendet wenn eine Datei includes/config.php existiert und in dieser die Konstante ‚COMPILER_INCLUDE_PATH‘ gesetzt wird. Das Deaktivieren/Aktivieren über das Backend tut nichts anderes, als dafür zu sorgen, dass diese Konstante gesetzt wird.
Wird die Kompilierung, dann werden zig tausend Files aus den diversen Verzeichnissen in includes/src kopiert. Nach jeder Änderung an den normalen Dateien bzw. jedem Magento-Update muss man die Dateien in includes/src neu aufbauen lassen. Ansonsten entstehen Diskrepanzen zwischen den normalen Dateien und den „Compiler-Dateien“, wie es mir in Ihrem Fall zu sein scheint. Warum bestimmte Dinge jetzt mit/ohne Compiler funktionieren, das wird sich leider nur in Kleinarbeit herausfinden lassen.
Was ich prinzipiell empfehle:
Wenn der Shop nun nicht läuft, steht fest, dass in Ihrer aktuellen Magento-Installation ein Problem besteht. Dieses muss in jedem Fall behoben werden, denn es wird vermutlich auch bei aktiviertem Compiler auftreten, sobald einmal die aktuellen Dateien in das includes/src-Verzeichnis kopiert werden.
Funktioniert alles, kann man den Compiler wieder aktivieren. Bitte beachten Sie aber bitte, dass der Compiler immer wieder für Probleme sorgen kann.
Ist auf Ihrem System ein Byte-Code-Cache wie z.B. APC aktiviert (das kann Ihnen Ihr Provider sagen), dann werden Sie durch den Compiler nach meiner Erfahrung nur geringe Performance-Vorteile (wenn überhaupt) erzielen. Ich kenne viele Entwickler, die den Compiler nicht einsetzen, weil die Rechnung Performance-Gewinn/Compiler-Probleme nicht aufgeht.
Hallo,
ich möchte mich kurz für den Tip bezüglich „Not enough permissions to create backup“ bedanken. Es lag bei mir an einem sonst nicht benötigten Ordner mit „700“. Mit deinem Tip konnte ich ich das Problem schnell finden und habe viel Zeit gespart. Danke.
Hallo, es freut mich, dass ich dir helfen konnte!
Ich habe auch ein Problem mit der Backup Funktion. Ich habe Ihren Beitrag über Google gefunden. Er ist sehr hilfreich, vielen Dank für die gute Beschreibung. Vielleicht können Sie mir ja auch helfen.
Ich habe Magento 1.7.2 bei einem Webspace Anbieter installiert. Es funktioniert auch soweit alles im Shop bis auf die Backupfunktion vom Shop.
Bei dem Anbieter steht die Funktion disk_free_space() nicht zur Verfügung. Im system.log wird diese Funktion in der includes/src/Mage_Backup_Filesystem.php bemängelt, Zeile 125
Ich habe nun in der Zeile den Wert mit einem Pseudowert ersetzt, vorher
$freeSpace = disk_free_space($this->getBackupsDir());
nun
$freeSpace = 100000000;
Die Funktion wird nun nicht mehr in der Log Datei bemängelt.
Ich habe für den Login in Magento einen Patch gesetzt:
/app/code/core/Mage/Core/Model/Session/Abstract/Varien.php
ab Zeile 78
$cookieParams = array('lifetime' => $cookie->getLifetime(),
'path' => $cookie->getPath()
// 'domain' => $cookie->getConfigDomain(),
// 'secure' => $cookie->isSecure(),
// 'httponly' => $cookie->getHttponly()
Genau das wird jedoch in dieser Datei /includes/src/__default.php im system.log bemängelt:
2012-09-22T20:04:52+00:00 ERR (3): Notice: Undefined index: httponly in /includes/src/__default.php on line 73492012-09-22T20:04:52+00:00 ERR (3): Notice: Undefined index: secure in /includes/src/__default.php on line 7351
2012-09-22T20:04:52+00:00 ERR (3): Notice: Undefined index: domain in /includes/src/__default.php on line 7353
2012-09-22T20:05:03+00:00 ERR (3): Notice: Undefined index: httponly in includes/src/__default.php on line 7349
2012-09-22T20:05:03+00:00 ERR (3): Notice: Undefined index: secure in /includes/src/__default.php on line 7351
2012-09-22T20:05:03+00:00 ERR (3): Notice: Undefined index: domain in /includes/src/__default.php on line 7353
In der Datei sind die Einträge ebenfalls auskommentiert, dies hat Magento nach meinen Änderungen in der oben genannten Datei gesetzt.
// 'domain' => $cookie->getConfigDomain(),// 'secure' => $cookie->isSecure(),
// 'httponly' => $cookie->getHttponly()
Jetzt ist die Frage was steht in den Variablen, das ich diese notfalls in der Datei manuell setzen kann?
$cookie->getConfigDomain(),$cookie->isSecure(),
$cookie->getHttponly()
Leider kann ich die Änderungen nicht in der Datei __default.php rückgängig machen, dann ist der Shop nicht aufrufbar. Das Leeren vom Cache hat auch nichts gebracht. Beim Backup kommt jedesmal die Meldung: „Nicht genügend Speicherplatz zum Erstellen einer Sicherung“. Es ist jedoch ein vielfaches an Platz noch vorhanden. Das Datenbankbackup funktioniert auch über den Shop. Die Dateirechte sind richtig gesetzt.
Vielleicht haben Sie ja noch ein Tipp für mich, vielen Dank
Entschuldigung für die vielen Daten.
Sven
Hallo Matthias,
nochmal als Nachtrag: Habe Magento nun in ein eigenes Verzeichnis verschoben. Somit werden die gefundenen und „gesperrten“ Logdateien des Servers gar nicht mehr beachtet und das Backup läuft einwandfrei. Ist vielleicht für alle interessant die bei Miet-Hostern sind und Magento im root liegen haben.
Ein Problem gelöst, inzwischen 10 neue aufgetan 😀
Hallo Matthias
So langsam fängt es an Spass zu machen 😉
Also: Datei hab ich gefunden (erst mal auf die Festplatte kopiert) und entsprechend geändert. Nur den Ordner wo sie hin soll kann ich nicht finden.
/app/code hab ich noch, danach kommt dann allerdings „community“ oder „core“.
Hab mal etwas in en Ordnern geblättert und hätte z.B.
/app/code/core/mage/backup anzubieten. Allerdings ohne „Filesystem“ ordner. Dort gibt es ein /helper Ordner, nur wenn ich die Datei dort hineinkopiere tut sich im log nichts.
(Habe Magento 1.7.0.1, ist da evt. etwas in den Verzeichnis-strukturen anders?)
Hallo Marco,
jaja, tief im Code wühlen, das ist was Schönes. 😉
Das Verzeichnis local und die darunter liegenden musst du selbst erstellen. Magento sieht automatisch nach, ob sich die Datei unter app/code/local/ (usw. befindet). Wenn nicht, dann sucht sie in app/code/community, dann in app/code/core und schließlich in lib/.
Hallo Matthias
Vielen Dank für die schnelle Antwort. Ich habe mal die genannten Verzeichnisse überprüft und beide sind auf 777. Wie gesagt, werden dort auch einwandfrei die Backups der Datenbank sowie Datenbank+Medien abgelegt. Nur bei System kommt eine Fehlermedung. Auf englisch lautet die Meldung: „Not enough permissions to create backup“. (Bin natürlich auch als Admin eingeloggt).
Vielleicht noch eine Idee wonach ich schauen könnte? 🙂
Hallo Marco,
danke für die Information. Sehe bitte im Log (system.log) nach. Dort könntest du noch eine andere Meldung erhalten, die das Problem genauer erklärt. Falls du den Log nicht aktiviert hast: das ist im Menüpunkt System > Configuration, in der linken Navigation Advanced > Developer, im Hauptbereich Abschnitt „Log Settings“ möglich. Die Datei liegt dann im Verzeichnis var/log deiner Magento-Installation.
Es kommen unterschiedliche Ursachen in Frage: neben fehlenden Schreibrechten können auch mangelnde Leserechte oder das Fehlen der zlib-Bibliothek von PHP den Fehler verursachen.
Hallo Matthias
Danke für den Tipp. Ich habe jetzt mal die Logs aktiviert und ein paar mal das System Backup gestartet. Als Ausgabe im Log erscheint dann jedes mal:
2012-07-20T06:20:15+00:00 DEBUG (7): Not enough permissions to read files for backup
Klingt ja dann nach mangelnden Leserechen. Leider steht da nicht, um welche Dateien es geht, denn eigentlich sind alle meine Ordner auf Rechte 775 und die Dateien auf 664 gesetzt. Da müßte lesen doch drin sein?!
Hallo Marco,
Magento geht bei der Überprüfung außer den var-Verzeichnissen wirklich (fast) alles durch. Vielleicht ist eine Datei oder ein Ordner beim Setzen der Rechte durchgerutscht.
Kopiere lib/Mage/Backup/Filesystem/Helper.php in app/code/local/Mage/Backup/Filesystem/Helper.php, suche in der kopierten Datei die Methode getInfo() und ersetze (kurz vor Ende der Datei)
if (($infoOptions & self::INFO_READABLE) && !$item->isReadable()) { $info['readable'] = false; }durch
if (($infoOptions & self::INFO_READABLE) && !$item->isReadable()) { Mage::log($item->getPathname(), null, 'backup_not_readable_files.log'); $info['readable'] = false; }Führst du das Backup noch einmal aus, dann siehst du in der neuen Log-Datei, welche Dateien/Verzeichnisse du anpassen musst.
War das Backup erfolgreich, dann lösche die Datei wieder aus app/code/local.
Hallo Matthias,
ich hab das Problem wie oben beschrieben ebenfalls in der Version 1.7.0.2
Ich hab die Helper.php entsprechend abgeändert und bekomme jetzt folgende Zeile in der Log-Datei:
2013-06-12T12:32:21+00:00 DEBUG (7): /homepages/26/d462515746/htdocs/logs/traffic.html/.md5sumsBei der Datei lassen sich allerdings die Rechte nicht ändern.
Hallo Sebastian,
die Datei hat mit Magento nichts zu tun. Da musst du dich bitte an deinen Provider wenden.
Hallo,
das ist mal ein klasse Blog. Habe das mit dem Backup in 1.7 gleich mal ausprobiert. Allerdings bekomme ich bei „System Sichern“ nur die Fehlermeldung „Keine ausreichende Rechte zum Erstellen einer Sicherung“. Die anderen beiden Backup-Optionen funktionieren einwandfrei und ich finde die entsprechenden Dateien im Backup Verzeichnis.
Was muss ich einstellen, damit ich auch das System Backup durchführen kann?
Hallo,
das klingt, als ob dein Webserver-User nicht die nötigen Rechte hat, um die Backup-Datei zu erstellen. Das Verzeichnis „var“ innerhalb der Magento-Installation muss beschrieben werden können (d.h. zum Beispiel die Rechte 777 haben). Falls es darunter schon ein Verzeichnis „backup“ gibt, muss auch das beschreibbar sein.
Theoretisch könnte es auch sein, dass der Webserver-User bestimmte Dateien/Verzeichnisse nicht auslesen darf, das ist aber eher unwahrscheinlich. Kannst du die englische Fehlermeldung im Wortlaut posten?
Hallo,
ich habe das mit dem Backup ausprobiert. Soweit war alle wie beschrieben, Nur wurde beim Aufruf des Magento Connect Mangers ein 404-Fehler ausgegeben. Kann das jemand bestätigen und vielleicht eine Lösung aufzeigen?
Hallo,
ich habe gerade mit einer frischen Installation ein System- und Datenbank-/Media-Backup gemacht. Nach dem Rollback konnte ich ganz normal auf den Magento-Connect-Manager zugreifen.
Hat es vielleicht etwas mit Dateirechten zu tun, siehe z.B. http://www.magentocommerce.com/boards/26245/viewthread/279007/?