How to create a backup (Sicherungskopie)?

Deutsches Forum
1

Hallo,

Kann mir jemand sagen, wie ich eine Sicherungskopie anfertigen kann? Bevor ich einen Shop upgraden kann, muss ich eine Sicherungskopie anfertigen. Und diese in eine Testumgebung … usw usw.

Wie erstelle ich diese Sicherungskopie?

Ist das möglich mit dem Exportmodul in EShop? Und wird dann die ursprüngliche Version miet kopiert?

Gruss,
Anne M

2

Ein Datenbank-Backup erstellest du einfach über PhpMyadmin. Einfach die Datenbank auswählen und dann über exportieren eine Sicherung ziehen.

Die Shop-Dateien kannst du einfach kopieren oder per FTP noch mal komplett runterladen.

3

Je nachdem wo du hostest, ist es auch möglich ein Backup-Script zu erstellen, mit dem du sowhl Datenbank als auch FTP-Daten in ein Zip-Paket packen kannst und dann nur noch die zwei Dateien herunter laden musst.

Auf dem lokalen Server wieder entpacken, config-Datei anpassen, Datenbank einspielen und fertig.

4

Wenn die Datenbank etwas größer ist kann ich die Installation von MySQLDumper empfehlen.

5

[QUOTE=Firefax;21579]Wenn die Datenbank etwas größer ist kann ich die Installation von MySQLDumper empfehlen.[/QUOTE]

Ja, das ist sicher auch eine gute Lösung. Mir persönlich ist der immer etwas umständlich und meine Datenbanken haben noch nicht dieses Limit erreicht (zumindest nicht, wenn ich sie mit gzip komprimiere), dass das nötig ist.

6

[OFFTOPIC]
Hallo,

[QUOTE=jkrug;21581]Mir persönlich ist der immer etwas umständlich[/QUOTE]
Ich bin der Autor des Dumpers und hätte gerne gewusst, was Du an der Handhabung umständlich findest. Backup / Backup starten - fertig. Im Vergleich zu PhpMyAdmin ist das doch Zucker. :wink:

Ok, hier ist der falsche Ort für Feedback zum Dumper. Deshalb lade ich Dich herzlich ein, in unserem Support-Forum genauer zu erklären, was Dir umständlich erscheint. Genau wie hier ist konstruktive Kritik immer willkommen.
[/OFFTOPIC]

7

[QUOTE=DSB;21655][OFFTOPIC]
Hallo,

Ich bin der Autor des Dumpers und hätte gerne gewusst, was Du an der Handhabung umständlich findest. Backup / Backup starten - fertig. Im Vergleich zu PhpMyAdmin ist das doch Zucker. :wink:

Ok, hier ist der falsche Ort für Feedback zum Dumper. Deshalb lade ich Dich herzlich ein, in unserem Support-Forum genauer zu erklären, was Dir umständlich erscheint. Genau wie hier ist konstruktive Kritik immer willkommen.
[/OFFTOPIC][/QUOTE]

Hallo,

ne ne, nicht falsch verstehen! Der Dumper ist eine prima Sache! Nur mir als Programmierer reicht ein PhpMyAdmin vollkommen. Der ist auf fast allen Severn mit installiert und ich kann damit sofort arbeiten.

Solange das geht, gibt es für mich einfach keinen Grund, noch ein Backup-Tool zu installieren.

“Umständlich” war hier sicher das falsche Wort. Sorry.

8

Nee, ich habe das nicht falsch verstanden - keine Sorge. :wink:
Mich hatte halt nur interessiert was genau Du meintest. Jetzt ist es klar. PMA ist bereits installiert und Du müsstest den Dumper zusätzlich installieren. Das kann ich nachvollziehen. :wink:

So, Ende des Offtopics und sorry für den kurzen Exkurs.

9

Danke.
Gruss,
Anne M

10

Mal ne Frage, es geht konkret um OXID 4.5.x.

Ich wollte gerade Testweise ein Datenbankbackup in eine andere Datenbank einspielen, mit MySQLDumper (neuste Version), bekomme aber immer eine Fehlermeldung bei den folgenden Tabellen:

MySQL meldet:
Access denied; you need the SUPER privilege for this operation

Fehler bei der Anfrage:
CREATE ALGORITHM=UNDEFINED DEFINER=xxx@xxx.db.1and1.com SQL SECURITY DEFINER VIEW oxv_oxactions AS select oxactions.OXID AS OXID,oxactions.OXSHOPID AS OXSHOPID,oxactions.OXTYPE AS OXTYPE,oxactions.OXTITLE AS OXTITLE,oxactions.OXTITLE_1 AS OXTITLE_1,oxactions.OXTITLE_2 AS OXTITLE_2,oxactions.OXTITLE_3 AS OXTITLE_3,oxactions.OXLONGDESC AS OXLONGDESC,oxactions.OXLONGDESC_1 AS OXLONGDESC_1,oxactions.OXLONGDESC_2 AS OXLONGDESC_2,oxactions.OXLONGDESC_3 AS OXLONGDESC_3,oxactions.OXACTIVE AS OXACTIVE,oxactions.OXACTIVEFROM AS OXACTIVEFROM,oxactions.OXACTIVETO AS OXACTIVETO,oxactions.OXPIC AS OXPIC,oxactions.OXPIC_1 AS OXPIC_1,oxactions.OXPIC_2 AS OXPIC_2,oxactions.OXPIC_3 AS OXPIC_3,oxactions.OXLINK AS OXLINK,oxactions.OXLINK_1 AS OXLINK_1,oxactions.OXLINK_2 AS OXLINK_2,oxactions.OXLINK_3 AS OXLINK_3,oxactions.OXSORT AS OXSORT from oxactions;

Jemand eine Idee?

11

[QUOTE=e-hahn;75619]
Jemand eine Idee?[/QUOTE]
Klar! Lass die Views bei der Sicherung aus. Diese solltest du dann beim Import wieder neu generieren.

Gruß Joscha

12

fehlende Rechte des DB-Users:

Access denied; you need the SUPER privilege for this operation

Sind beide Datenbanken bei 1+1? Hat der bei 1+1 das Recht für CREATE VIEW?

13

Ja sind beide DBs bei 1&1.
Die Datenbanken können bei einer neu Installation ja auch erstellt werden, nur beim einspielen eines Backups anscheinend nicht, ich steh da gerade etwas auf dem Schlauch…

14

dann wie Joscha geschrieben hatte, lass bei dem Dump die Tabellen mit dem Präfix “oxv_” weg.
Nach dem Import in die neue DB im zugehörigen Shop-Backend unter Service -> Tools die VIEWS aktualisieren (und /tmp leeren).

15

Alles klar, die werden dann automatisch neu erstellt…?

16

ja, ganz genau

17

Ich hätte da auch mal eine Frage :slight_smile:

Ich würde gerne wissen, ob ich beim Backup eines Oxid Shops per FTP Programm (ich benutze Filezilla) darauf achten sollte in welchem Modus ich die Shopdateien runterlade. Eher automatisch oder doch binär? Oder ganz egal?!

Vielen Dank im Vorraus für eure Hilfe.

18

im Zweifel lieber binär (vor allem, wenn verschlüsselte Moduldateien dabei sind)

19

Besten Dank!!!

20

Hi,

ich habe Sputnik mal getestet - als Backup Tool und nicht für einen Umzug…

d.h. ich habe bei den DB-Infos nichts eingetragen - nach dem Start erschien auch eine entsprechende Meldung… soweit, so gut…

… nur, dass der Shop anschließend eine 500er Meldung präsentierte - Lösung war: die config.inc.php wurde überschrieben!!

die sollte man in einem solchen Script “nie nicht” direkt anfassen!