Web Backup funktioniert nicht

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
 

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?
 

Till

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

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:

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...
 

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.
 

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?
 

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.
 

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...
 

Till

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

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.
 

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:

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
 

fuxifux

Member
Die Zeile ist im git zwar bereits geändert:
PHP:
if($retval == 0 || $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 == 0 || $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 == 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\*'.$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.
 

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 == 0 || ($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.
 

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.
 

ramsys

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

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

Ich hatte auch vorher die Datenbank keinem web zugeordnet, sondern nur dem Client

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.
 

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.
 

Werbung

Top