# Web Backup funktioniert nicht



## fuxifux (3. Jan. 2014)

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 (4. Jan. 2014)

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 (4. Jan. 2014)

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


----------



## fuxifux (4. Jan. 2014)

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


----------



## fuxifux (5. Jan. 2014)

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 (5. Jan. 2014)

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 (6. Jan. 2014)

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:

```
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?


----------



## Till (6. Jan. 2014)

> Müsste ".." auch dem user gehören?


nein. das ist ok so.

Was ist mit zip und sudo?


----------



## fuxifux (6. Jan. 2014)

Zip:

```
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:


```
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 (8. Jan. 2014)

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


```
$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:

```
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 (8. Jan. 2014)

> 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 (8. Jan. 2014)

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


----------



## Till (8. Jan. 2014)

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 (8. Jan. 2014)

Die Zeile ist im git zwar bereits geändert:

```
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:

```
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:

```
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:


```
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 (9. Jan. 2014)

*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:

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


----------



## Till (9. Jan. 2014)

Danke! Ich hab es im bugtracker hinzugefügt.


----------



## ramsys (9. Jan. 2014)

Zitat von Till:


> ISPConfig / ISPConfig 3 | GitLab


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.


----------



## fuxifux (9. Jan. 2014)

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 (9. Jan. 2014)

Zitat von fuxifux:


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



Zitat von fuxifux:


> 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 (9. Jan. 2014)

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.


----------



## ramsys (9. Jan. 2014)

Zitat von fuxifux:


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


Ich weiß, ich wollte für den anderen Punkt nur nicht extra einen eigenen Thread aufmachen, wenn in diesem Zusammenhang bereits nachgesehen wird.


----------



## fuxifux (9. Jan. 2014)

Alles klar, der Ort an dem für Dein Problem nachgeschaut werden müsste ist aber ein ganz anderer. In cron_daily.php wird zwar der backup_intervall aus der Datenbank ausgewertet, aber nicht beeinflusst.

Ich hab auch keine Ahnung wo und wie das in ISPConfig gemacht wird.
So weit möchte und kann ich ich auch gar nicht in ISPConfig eintauchen - aus Zeitmangel...


----------



## Till (9. Jan. 2014)

> Ich hab auch keine Ahnung wo und wie das in ISPConfig gemacht wird.


Im Interface, backup reiter der webseite.



> In der Tabelle web_database ist für backup_intervall überall 0 eingetragen.


Dann hast Du ganz einfach backups in dem web deaktiviert. Wenn Du backups erhalten möchtest, dann muss die Anzahl der backups auf dem backup tab der webseite > 0 sein.


----------



## fuxifux (9. Jan. 2014)

Zitat von Till:


> Im Interface, backup reiter der webseite.


Ich weiß - mir ging es darum, wo diese Funktionen programmiert sind,
ramsys hat anscheinend das Problem, dass bei ihm unter Verwendung der Git-Version die Datenbank nicht mitgesichert wird bzw. bei ihm backup_intervall auf 0 bleibt... und hat gemeint, wenn wir hier schon im code nachschauen könnten wir das auch gleich kären.

Das wäre aber eigentlich als neuer Thread im Entwicklerforum besser aufgehoben...


----------



## ramsys (10. Jan. 2014)

Zitat von Till:


> Dann hast Du ganz einfach backups in dem web deaktiviert.


Das Backup ist definitiv aktiviert und funktioniert ja auch für die Webseiten (zip). Nur die Datenbank(en) wird nicht mit gesichert.



Zitat von Till:


> Wenn Du backups erhalten möchtest, dann muss die Anzahl der backups auf dem backup tab der webseite > 0 sein.


Die Anzahl der Backups steht per default schon auf 1 (0 gibt es gar nicht). Die Aktivierung erfolgt über das Backup-Intervall (kein backup, täglich, wöchentlich, monatlich).


----------



## ramsys (10. Jan. 2014)

Zitat von fuxifux:


> dass bei ihm unter Verwendung der Git-Version die Datenbank nicht mitgesichert wird bzw. bei ihm backup_intervall auf 0 bleibt...


Korrekt 



Zitat von fuxifux:


> Das wäre aber eigentlich als neuer Thread im Entwicklerforum besser aufgehoben...


Sofern notwendig weil Bug, mache ich auch gerne einen neuen Thread dazu auf.


----------



## shadowcast (5. Feb. 2014)

Morgen,

ich fand gerade diesen Thread, welcher wohl genau mein aktuelles Thema Beschreibt.

Ich hatte den Backup Modus auf ROOT, wo mir täglich 2 Dateien (Datenbank und Webinhalt) angelegt wurden.
Nun habe ich auf den Webbenutzer umgestellt und seitdem bekomme ich nur noch die Datenbank ohne den Webinhalt gesichert.

Gibt es dafür bereits eine funktionierende Lösung, um Datenbank & Webinhalte zuverlässig zu sichern?
Mit dem Patch-Tool erhielt ich die gleiche Fehlermeldung wie bereits erwähnt.

LG


----------



## fuxifux (5. Feb. 2014)

Morgen,

Das Problem wird in er nächsten Version behoben sein.

Bis dahin hilft es, in der Datei /usr/local/ispconfig/server/cron_daily.php die Zeile 1131 zu ändern:
Alt:

```
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);
```
Neu:

```
if($retval == 0 || $retval == 12) 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);
```
Es ändert sich nur der Inhalt der ersten Klammer auf "$retval == 0 || $retval == 12"

Dann solte bis zum nächsten Update von ISP-Config das Web-Backup auch funktionieren.


----------



## shadowcast (5. Feb. 2014)

Vielen Dank.
Habe ich umgesetzt und bin schon gespannt auf morgen.


----------



## shadowcast (6. Feb. 2014)

Morgen,

die Änderungen haben leider nicht geklappt.
Es wird immer noch NUR die Datenbank gesichert. Ich habe auch gerade überprüft, ob die gestern eingetragene Zeile noch vorhanden ist, was der Fall ist.
Müsste ich wegen der "12" noch an einer anderen Stelle etwas anpassen?

Die Datenbank Sicherung ist eine .gz Datei.
ZIP ist installiert.
Das Cron Protokoll zeigt nichts ungewöhnliches.

LG


----------



## Till (6. Feb. 2014)

Ist sudo auch installiert?


----------



## shadowcast (6. Feb. 2014)

Ja auch sudo ist installiert.


----------



## florian030 (6. Feb. 2014)

Es reicht nicht, in /usr/local/ispconfig/server/cron_daily.php die Zeile nur die Zeile 1131 zu ändern.
Dadurch wird nur das Archiv erstellt. Du musst aber auch Zeile 1137 entsprechend anpassen, damit ein retval von 1 oder 12 bei zip möglich ist.

Die Zeile 1137 sieht dann so aus:


```
if($retval == 0 || ($backup_mode != 'userzip' && $retval == 1) || ($backup_mode == 'userzip' && $retval == 12)) {
```


----------



## shadowcast (6. Feb. 2014)

Alles klar. Vielen Dank.

Dann morgen auf ein Neues.

Perfekt. Das hat jetzt funktioniert...

LG


----------

