# Backups von Datenbanken



## ramsys (3. März 2014)

Hallo Till,

wenn ich mich richtig erinnere gab es ein Problem beim Backup, wenn Webserver und Datenbankserver auf verschiedenen Servern installiert sind (Multiserver-Setup).

Ist das in 3.0.5.4 behoben? Im Bugtracker konnte ich dazu nichts finden. In der aktuellen 3.0.5.4-dev werden keine Backups der Datenbanken angelegt.


----------



## ramsys (4. März 2014)

Okay, das hat mich gerade nicht in Ruhe gelassen 

Die DB-Backups können auch nicht erstellt werden, da in der Tabelle web_database die Spalte backup_interval den Wert "0" hat. In der Datei database_edit.php wird der entsprechende Wert aus der Tabelle web_domain geholt. Die Tabelle web_domain hat aber gar keine Einträge, da die Webseiten ja auf einem anderen Server liegen.

_Auszug database_edit.php_:


```
$web = $app->db->queryOneRecord("SELECT * FROM web_domain WHERE domain_id = ".$app->functions->intval($this->dataRecord["parent_domain_id"]));

$backup_interval = $app->functions->intval($web['backup_interval']);

$sql = "UPDATE web_database SET sys_groupid = '$sys_groupid', backup_interval = '$backup_interval', backup_copies = '$backup_copies' WHERE database_id = ".$this->id;
```
Bug oder Gedankenfehler bei mir?


----------



## florian030 (4. März 2014)

Ich habe mir eben das aktuelle stable-version aus dem git installiert und habe kein Problem mit den Backups feststellen können.

Mal davon abgesehen, dass ich deine Beispiel-Zeilen nicht wirklich finden konnte.

Hast Du dieses Problem, wenn DB und WEB auf verschiedenen Servern liegen oder immer?


----------



## ramsys (4. März 2014)

Das kann ja auch nicht funktionieren, da der Wert in der web_
	
	



```

```
domain ein String ist (none, daily) und in der web_database Integer (0). Durch die Umwandlung steht dann in der web_database immer 0.

Das wurde erst in 7c19f2dbb4608ef6b3f219d45490b25aa05e848c vor zwei Tagen behoben. Deshalb funktioniert es jetzt bei Dir 



Zitat von florian030:


> Hast Du dieses Problem, wenn DB und WEB auf verschiedenen Servern liegen oder immer?


Ich werde den aktuellen Commit nachher mal installieren und hier berichten, wie es sich dann bei getrennten Servern verhält.

@florian030 Danke für Test


----------



## ramsys (5. März 2014)

Der Bug wurde von Falko im Git behoben. Nach dem Update werden nun in beiden Tabellen (web_domain, web_database) die Werte korrekt als string eingetragen (none, daily). Auch bei getrennten Servern von Web und Datenbank!

Es war nur notwendig, bei allen betroffenen Webseiten den Datensatz manuell zu aktualisieren. Ich werde den Durchlauf heute Nacht abwarten und sehen, ob dann alle Daten wie gewünscht im Backup-Verzeichnis liegen.


----------



## ramsys (5. März 2014)

Zitat von florian030:


> Mal davon abgesehen, dass ich deine Beispiel-Zeilen nicht wirklich finden konnte.


ISPConfig / ISPConfig 3 | GitLab
ISPConfig / ISPConfig 3 | GitLab
ISPConfig / ISPConfig 3 | GitLab


----------



## ramsys (5. März 2014)

BTW Kann man eigentlich, um z.B. das Backup vorzeitig zu simulieren, die cron_daily.sh manuell aufrufen? Oder kommen dann die anderen Funktionen und vor allem die Statistiken durcheinander?


----------



## Till (5. März 2014)

Das würde die Statistiken durcheinander bringen, also nichts für ein Produktivsystem.


----------



## ramsys (5. März 2014)

Zitat von Till:


> Das würde die Statistiken durcheinander bringen, also nichts für ein Produktivsystem.


Danke, das habe ich mir fast schon so gedacht


----------



## florian030 (5. März 2014)

Du könntest bestenfalls eine zweite cron_daily.sh anlegen, die eine zweiter cron_daily.php aufruft. In dieser nimmst Du dann Statistiken, Log-Handling und das Quota-Handling raus.


----------



## ramsys (5. März 2014)

Zitat von florian030:


> Du könntest bestenfalls eine zweite cron_daily.sh anlegen, die eine zweiter cron_daily.php aufruft.


Gute Idee, lohnt sich aber wahrscheinlich nicht da ich davon ausgehe, dass jetzt alles reibungslos funktioniert. Ich werde einfach noch ein paar Stunden warten und mich inzwischen mit dem Rechnungsmodul weiter beschäftigen


----------



## ramsys (7. März 2014)

Hier das Ergebnis:

Wenn Webserver und Datenbankserver auf getrennten Servern liegen, werden nur die Webseiten beim Backup berücksichtigt, keine Datenbanken.

Auf dem Webserver hat die Tabelle "web_domain" den korrekten Eintrag für "backup_interval" und auf dem Datenbankserver die Tabelle "web_database".


----------



## florian030 (7. März 2014)

Die Backups für die Datenbanken sollten dann doch aber auf dem DB-Server erstellt werden?


----------



## ramsys (7. März 2014)

Zitat von florian030:


> Die Backups für die Datenbanken sollten dann doch aber auf dem DB-Server erstellt werden?


Danke, dort hatte ich gerade überhaupt nicht nachgesehen, nur im Interface. Die Backups der Datenbanken liegen tatsächlich auf dem Server.

Dann fehlt nur noch die Anzeige der Datenbank-Backups im Interface, sowie die Möglichkeit des Downloads und des Restore.


----------



## florian030 (7. März 2014)

Stehen die Backups denn in der Tabelle web_backup auf dem Server auf dem das Interface läuft oder nur auf dem DB-Server? 

Die Backup-Listen werden nämlich durch SELECT * FROM web_backup WHERE parent_domain_id = eingelesen.


----------



## ramsys (7. März 2014)

Auf dem Webserver stehen in der Tabelle web_backup alle Backups vom backup_type "web" und auf dem Datenbankserver alle Backups vom backup_type "mysql".

Auf dem Server des Interface sind in der Tabelle web_backup beide Backups vorhanden (web und mysql), mit der jeweils korrekten  server_id.

Bei einem "SELECT * FROM web_backup WHERE parent_domain_id = xx" auf dem Server des Interface würden also 2 Datensätze gefunden werden, auf dem Webserver nur einer.

Dabei ist mir noch aufgefallen, dass "filesize" in der Tabelle web_backup immer leer ist.


----------



## florian030 (7. März 2014)

Für die Ausgabe entscheidend ist die Datenbank, die auf dem Server mit dem Interface verwendet wird.

Dass filesize in der Tabelle leer ist, ist schon richtig. Die Anzeige der Größen der Backups ist nur per Patch oder mit master-git möglich. Letzteres würde ich aber nicht produktiv einsetzen.


----------



## ramsys (7. März 2014)

Zitat von florian030:


> Für die Ausgabe entscheidend ist die Datenbank, die auf dem Server mit dem Interface verwendet wird.


Und dort befinden sich jeweils 2 Datensätze (web und mysql) unter der gleichen parent_domain_id und unterschiedlicher server_id. Nur wird im Interface lediglich der Datensatz "web" angezeigt.

Im Gegensatz dazu befinden sich in dieser Tabelle auch jeweils 2 Datensätze (web und mysql) unter der gleichen parent_domain_id und gleicher server_id, wo also Webserver und Datenbankserver nicht getrennt sind. Hier werden im Interface korrekterweise beide Datensätze "web" und "mysql" angezeigt.


----------



## ramsys (7. März 2014)

Zitat von florian030:


> Die Backup-Listen werden nämlich durch SELECT * FROM web_backup WHERE parent_domain_id = eingelesen.


WHERE parent_domain_id = xx *AND* server_id = xx

_interface/lib/classes/plugin_backuplist.inc.php:_


```
$web = $app->db->queryOneRecord("SELECT server_id FROM web_domain WHERE domain_id = ".$app->functions->intval($this->form->id));
		$sql = "SELECT * FROM web_backup WHERE parent_domain_id = ".$app->functions->intval($this->form->id)." AND server_id = ".$app->functions->intval($web['server_id'])." ORDER BY tstamp DESC, backup_type ASC";
		$records = $app->db->queryAllRecords($sql);

		$bgcolor = "#FFFFFF";
		if(is_array($records)) {
			foreach($records as $rec) {

				// Change of color
				$bgcolor = ($bgcolor == "#FFFFFF")?"#EEEEEE":"#FFFFFF";
				$rec["bgcolor"] = $bgcolor;

				$rec['date'] = date($app->lng('conf_format_datetime'), $rec['tstamp']);
				$rec['backup_type'] = $wb[('backup_type_'.$rec['backup_type'])];

				$records_new[] = $rec;
			}
		}

		$listTpl->setLoop('records', @$records_new);
```


----------



## florian030 (7. März 2014)

Das ist dann wohl ein Problem, wenn man eine dev-Version verwendet. 

Nimm doch mal testweise 
	
	



```
" AND server_id = ".$app->functions->intval($web['server_id']).
```
 raus.

Das


----------



## ramsys (7. März 2014)

Zitat von florian030:


> wenn man eine dev-Version verwendet.


Da diese aber kurz vor dem final steht, ein nicht unwesentlicher Bug, den ich im Bugtracker aber noch nicht gefunden habe


----------



## florian030 (7. März 2014)

Schon klar.Daher ja auch meine Frage, ob Du das mal ohne server.id versucht hast.


----------



## ramsys (7. März 2014)

Zitat von florian030:


> ob Du das mal ohne server.id versucht hast.


Nein noch nicht. Wird denn geprüft, ob die parent_domain_id nur einmal im System vorkommt, z.B. bei mehreren Webservern? Nicht, dass die Backups dann auf dem falschen Server liegen.


----------



## Till (7. März 2014)

parent_domain_id bezieht sich auf die domain_id spalte der web_domain Tabelle, die ist auto increment, eine webseite mit der ID kann in einem ispconfig cluster genau einmal vorkommen.

3.0.5.4 steht kurz vor der beta, eine Betaversion ist dafür da die Software einer breiteren Öffentlichkeit zugänglich zu machen um etwaige Bugs zu finden. Nach einer oder mehreren beta Versionen kommen dann die RC Releases und dann die Final. Wenn ein Bug nicht im Bugtracker steht, dann postet Ihn bitte da, dafür ist der Bugtracker ja gedacht. Denn was hier im Forum aber nicht im Bugtracker steht, wird vor Freigabe des Releases nicht geprüft, also bitte Bugs immer im Bugtracker eintragen, wenn sie dort noch nicht stehen.


----------

