Web Backup funktioniert nicht

Dieses Thema im Forum "Installation und Konfiguration" wurde erstellt von fuxifux, 3. Jan. 2014.

  1. fuxifux

    fuxifux Member

    Ich habe Debian 6.0 und ISPConfig 3.0.5.3 in einem OpenVZ-Container laufen.

    Vor kurzem hab ich bei einem Web das tägliche Backup aktiviert(das erste mal, dass ich diese Funktion verwenden möchte).

    Die Backup-Ordner und die Symlinks beim Benutzer-web werden erstellt, es werden aber keine Backups erzeugt.

    (Eingestellt auf tägliches Backup - 1 Version behalten)

    Unter system-config ist Userzip eingestellt.

    Nachdem ich im cron_daily.php die Stelle mit dem exec-Befehl gefunden habe, hab ich es erweitert, um den Rückgabewert in eine Datei zu speichern.

    Der Rückgabewert ist "12" - das würde bei zip "zip hat nichts zu tun" bedeuten...

    Kann mir jemand weiterhelfen, wo und wie ich den Fehler eingrenzen oder herausfinden kann?
    Oder gibt es etwas, das man tun muss wenn man von vorherigen Versionen auf 3.0.5.3 geupdatet hat(alles waren stable-releases)

    Danke
    fuxifux
     
  2. fuxifux

    fuxifux Member

    Jetzt hab ich zum Testen dem Web auch eine Datenbank zugeordnet.

    Seither wird das Backup erstellt, aber nur die Datenbank ist im Backup enthalten.

    Gibt es irgendwelche Tips, was ich beim Web falsch gemacht haben könnte, dass es beim Backup ausgeklammert ist?
     
  3. Till

    Till Administrator

    Schau mal nach ob sudo installiert ist und ob die dateien im web ordner dem user dieses webs gehören.
     
  4. fuxifux

    fuxifux Member

    sudo ist installiert, es kommt eine "usage"-meldung wenn ich sudo allein eingebe.

    Die Dateien im Ordner web gehören dem user des webs und auch zur gruppe des client.(ich hab das aber nicht für alle unterordner angeschaut...)

    Was mir heute noch aufgefallen ist: ich hab heute das patch für die ISPConfig-Portalseite eingespielt und wollte auch dieses: "3053_backupdownload" das wurde aber mit dem fehler:

    patching file interface/lib/classes/plugin_backuplist.inc.php
    Hunk #1 FAILED at 57.
    1 out of 1 hunk FAILED -- saving rejects to file interface/lib/classes/plugin_backuplist.inc.php.rej

    abgebrochen...
     
    Zuletzt bearbeitet: 4. Jan. 2014
  5. fuxifux

    fuxifux Member

    Was mir auch aufgefallen ist: die Backups erscheinen in ISPConfig mit
    Type: MySQL Database

    Wie kann ich denn herausfinden, wie Systemuser und Gruppe, ISPConfig-User und Name zusammenhängen?

    Ich hab irgendwie das Gefühl, dass da etwas nicht stimmt... kann das davon kommen, dass ich das Backup als Administrator eingeloggt eingerichtet habe? Das SQL-Backup funktioniert ja auch so...
     
  6. Till

    Till Administrator

    Mit dem admin login ht es nichts zu tun. Mach ein ls -la im web folder und vergleiche den user und die gruppe der dortigen datein mit dem web user und gruppe in der web_domain tabelle in der ispconfig mysql datenbank.
     
  7. fuxifux

    fuxifux Member

    Hier die Daten aus der Tabelle:
    http://www.computerauswertung.at/grafik/2014-01-06_12.39.58.png

    und hier die Ausgabe aus der shell:
    Code:
    root@server:/var/www/clients/client2/web4/web# ls -la
    total 296
    drwx--x--- 22 web4 client2  4096 Oct 27 06:18 .
    drwxr-xr-x 10 root root     4096 Dec 26 00:37 ..
    drwxr-xr-x  6 web4 client2  4096 Dec  8  2012 cache
    drwxr-xr-x 15 web4 client2  4096 Dec  8  2012 components
    drwxr-xr-x  3 web4 client2  4096 Dec  8  2012 gallery
    drwxr-xr-x  6 web4 client2  4096 Dec  8  2012 images
    drwxr-xr-x  8 web4 client2  4096 Dec  8  2012 includes
    -rw-r--r--  1 web4 client2  2052 Dec  8  2012 index.php
    drwxr-xr-x  4 web4 client2  4096 Dec  8  2012 installation
    drwxr-xr-x  5 web4 client2  4096 Dec  8  2012 language
    drwxr-xr-x 16 web4 client2  4096 Dec  8  2012 libraries
    drwxr-xr-x  2 web4 client2  4096 Dec  8  2012 logs
    drwxr-xr-x  8 web4 client2  4096 Dec  8  2012 media
    drwxr-xr-x 23 web4 client2  4096 Dec  8  2012 modules
    drwxr-xr-x 15 web4 client2  4096 Jan  6 00:37 stats
    drwxr-xr-x  7 web4 client2  4096 Dec  8  2012 templates
    drwxr-xr-x  2 web4 client2  4096 Nov 23 23:04 tmp
    
    Müsste ".." auch dem user gehören?
     
  8. Till

    Till Administrator

    nein. das ist ok so.

    Was ist mit zip und sudo?
     
  9. fuxifux

    fuxifux Member

    Zip:
    Code:
    root@server:~# zip -v
    Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
    This is Zip 3.0 (July 5th 2008), by Info-ZIP.
    Currently maintained by E. Gordon.  Please send bug reports to
    the authors using the web page at www.info-zip.org; see README for details.
    
    sudo:

    Code:
    root@server:~# sudo -V
    Sudo version 1.7.4p4
    .....
    
    sollten also beide installiert sein.

    Das SQL-Backup wird ja auch als zip erstellt, nur die Daten aus dem /web - Ordner fehlen.
     
  10. fuxifux

    fuxifux Member

    Jetzt hab ich mir die im ZIP-Befehl eingesetzten Variablen in eine Datei speichern lassen:

    Code:
    $web_path: /var/www/clients/client2/web4 
    $web_user: web4 
    $web_group: client2 
    $web_backup_dir: /var/backup/web4 
    $web_backup_file: web4_2014-01-08_00-35.zip 
    $http_server_user: www-data
    und damit folgenden Konsolen-Befehl nachgebaut:
    Code:
    cd /var/www/clients/client2/web4 && sudo -u web4 find . -group client2 -print 2> /dev/null | zip -b /tmp --exclude=backup\* --symlinks /var/backup/web4/web4_2014-01-08_00-35.zip -@
    Das komische ist, dass dieser Befehl zumindest auf der Konsole als root problemlos funktioniert und die zip-Datei erstellt.

    Jetzt stellt sich nur mehr die Frage warum das aus dem cron_daily.php heraus nicht funktioniert.

    Als welcher User wird denn die Datei bzw der cron ausgeführt?

    Der Fehlercode "12" - Zip hat nichts zu tun kam übrigens vom 2. Befehl, der die Daten des user "www-data" zippen soll.

    Langsam gehen mir die Ideen aus...
     
  11. Till

    Till Administrator

    root. Die cron_daily.sh welche dann die cron_daily.php aufruft steht ja in der root crontab (siehe: crontab -l als root ausführen).

    Wenn Der Befehl als root manuell läuft, dann weiß ich auch nicht woran es noch liegen kann. Außer vielleicht an der PATH vraable, cron_daily.sh setzt diesen path:

    PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin

    versuch also mal auf der shell:

    PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin
    cd /var/www/clients/client2/web4 && sudo -u web4 find . -group client2 -print 2> /dev/null | zip -b /tmp --exclude=backup\* --symlinks /var/backup/web4/web4_2014-01-08_00-35.zip -@

    ob es dann auch noch geht.
     
  12. fuxifux

    fuxifux Member

    Fehler in der cron_daily.php gefunden:

    Zeile 1130: Der erste exec-Befehl erstellt das zip aus den webGruppen-Dateien. - Das funktioniert.
    Zeile 1131: Bei Fehlercode 0 wird versucht ein zip aus den www-data - Dateien zu erstellen.
    Weil ich fastCGI mit suexec benutze und deshalb keine solchen Dateien vorhanden sind erzeugt das den Fehlercode 12 "zip hat nichts zu tun"

    Zeile 1137: Dieser Fehlercode(die Variable $retval ist für beide Befehle die selbe) wird dann ausgewertet und das Backup wieder gelöscht und nicht in die Datenbank eingetragen.

    Ich werde das mal korrigieren und morgen berichten, ob das Backup vorhanden und eingetragen ist...
     
    Zuletzt bearbeitet: 8. Jan. 2014
  13. Till

    Till Administrator

    Danke für die Infos!

    Du kannst Dir auch mal das cron_daily.php hier ansehen, es kann sein dass wir da schon was geändert haben. Mich wundert nur dass es bei den meisten usern auch so geht, denn php-fcgi + suexec ist ja standard.

    ISPConfig / ISPConfig 3 | GitLab
     
  14. fuxifux

    fuxifux Member

    Die Zeile ist im git zwar bereits geändert:
    PHP:
    if($retval == || $backup_mode != 'userzip'){ // tar can return 1 (due to harmless warings) and still create valid backups
    weil es anscheinend bei tar auch andere return values gibt, sollte aber auf:
    PHP:
    if($retval == || $retval == 12 || $backup_mode != 'userzip'){ // tar can return 1 and zip can return 12(due to harmless warings) and still create valid backups
    geändert werden, damit es auch mit "12" funktioniert.

    Besser fände ich es, die Zeile des 2. zip-Aufruf:
    PHP:
    if($retval == 0exec('cd '.escapeshellarg($web_path).' && sudo -u '.escapeshellarg($web_user).' find . -user '.escapeshellarg($http_server_user).' -print 2> /dev/null | zip -b /tmp --exclude=backup\*'.$backup_excludes.' --update --symlinks '.escapeshellarg($web_backup_dir.'/'.$web_backup_file).' -@'$tmp_output$retval);
    zu ändern in:

    PHP:
    if($retval == 0) {
        
    exec('cd '.escapeshellarg($web_path).' && sudo -u '.escapeshellarg($web_user).' find . -user '.escapeshellarg($http_server_user).' -print 2> /dev/null | zip -b /tmp --exclude=backup\* --update --symlinks '.escapeshellarg($web_backup_dir.'/'.$web_backup_file).' -@'$tmp_output$retval);
        if(
    $retval == 12$retval 0// zip returns 12 if no files are added, that's no error in this case
    }
    dann würde die Änderung ausschliesslich für den speziellen Fall wirken.

    Die gleiche Änderung könnte man auch beim tar-Aufruf machen, und die Entscheidung, ob ein Backup zustande kam, wieder auf $retval>0 reduzieren.
    Momentan werden im git returncodes >0 beim tar-backup gar nicht beachtet.(die werden vermutlich auch nicht oft vorkommen)

    Kann es sein, dass in einem normal erstellten web von haus aus dateien mit user:www-data vorkommen? Bei mir nämlich nicht...

    Ich bin schon gespannt, ob ich morgen ein Backup im Verzeichnis hab.
     
  15. fuxifux

    fuxifux Member

    Geschafft!

    Das Backup ist jetzt wie erwartet in 2 Ausführungen vorhanden: Website files und Datenbank!

    Ich hab es mit einer Änderung der Zeile 1163 in cron_daily.php im ISPConfig / ISPConfig 3 | GitLab gelöst:
    PHP:
                        if($retval == || ($backup_mode != 'userzip' && $retval == 1) || ($backup_mode == 'userzip' && $retval == 12)){ // tar can return 1, zip can return 12(due to harmless warings) and still create valid backups
    So werden auch andere returncodes als 1 beim tar-backup wieder beachtet.

    Wie ihr das letztendlich einbaut, müsst ihr selbst entscheiden.
     
  16. Till

    Till Administrator

    Danke! Ich hab es im bugtracker hinzugefügt.
     
  17. ramsys

    ramsys Member

    Ich habe gerade gesehen, dass damit das Backup der Webseite fehlerfrei funktioniert. Es werden aber keine Datenbanken gesichert. In der Tabelle web_database ist für backup_intervall überall 0 eingetragen.

    Änderungen in ISPConfig werden zwar in web_domain übernommen, aber nicht in web_database.
     
  18. fuxifux

    fuxifux Member

    Dann kann es sein, dass die Datenbank keinem Web zugeordnet ist.

    Unter Sites/databases muss in der Tabelle in der Spalte "Website" das jeweilige Web eingetragen sein, sonst wird die Datenbank nicht mit gesichert.

    Ich hatte auch vorher die Datenbank keinem web zugeordnet, sondern nur dem Client - dann wird sie nicht mit dem Web mit gesichert.
     
  19. ramsys

    ramsys Member

    Das ist sie :) In der Tabelle web_database ist die richtige Domain auch unter parent_domain_id eingetragen.

    Dort hattest Du auch noch nicht die Git-Version installiert, wenn ich das richtig sehe.

    BTW Die Datenbank kann keinem Client zugeordnet werden, das geht nur für den Datenbank-User.
     
  20. fuxifux

    fuxifux Member

    Ich hab jedenfalls die parent_domain_id des webs(natürlich per Interface) erst später eingetragen, und seit ich das so habe wurde die Datenbank mit gesichert bzw. Änderungen wurden beim Web und der Datenbank vorgenommen.

    Ich verwende allerdings immer noch die letzte stable-Version 3.0.5.3 - und werde das auch erst bei einer neuen stable-Release ändern!!

    Die Sprache kam hier nur auf die GIT-Version, weil ich nach Till's Hinweis nachgeschaut habe, ob mein Problem nicht dort schon behoben ist.
     

Diese Seite empfehlen