incremental backup heisst bei firebird nbakup, ist ein extra binary und gibt es seit
fb20, also ca 2006.
Da wir im allgemeinen blobs gar nicht erst in Unmengen in der production
db
drin lassen, sondern per trigger und execute statement on external in extra
blob datenbanken übertragen, deren ältere versionen dann je nach datenvolumen
jährlich oder monatlich readonly geschaltet werden, sind bei vielen Kunden Production
datenbanken vielleicht 10-20 gb groß und ob dann in den blobs 500GB archiviert sind ist
egal, weil die gar nicht täglich oder auch wochenweise gesichert werden müssen, denn die
werden nur nach der Umstellung auf Readonly ein letztes mal gesichert.
Die Inhalte holen wir dann entweder über views oder direkt per sp jeweils wieder mit execute
statement on external auch den archivdatenbanken, es kann dabei auch ein ganz anderer server
sein, auf dem die liegen. Geändert oder gelöscht werden die großen (pdf, docs, emails, etc)
Inhalte eh nicht mehr, daher vermeiden wir auf dem weg das wir endlos lang laufende Backups
haben. Und auf den von uns vertrieben IFS Firebird Servern braucht ein Backup für eine 20GB
Datenbank realistisch 30-45 Sekunden, warum sollen wir dann inkrementell sichern und im
Restore Fall erst mal wieder sämtliche Inkremente zusammensuchen und wenn nur eines fehlt
kann ich alles wegwerfen. Wir nutzen auch nicht nbackup, aber wer da vielelicht andere
Strukturen hat oder langsamere Server, why not.
Changeviews kenn ich vom Namen und von der Idee dahinter nur begrenzt, weil ich auch das
nicht brauch. Mit der Art der Replikation, wie wir die machen, haben wir zum Beispiel
bei einem mittelständischen Betrieb mit ca 60 Mitarbeitern alle datensätze in allen
Tabellen als redo und undo
sql in einer extra log
db, die mittlerweile in Richtung
600GB geht, aber auch auf mehrere verteilt ist. Durch aufruf einer SP mit einer
Transaction ID können wir dabei alles was in dieser Transaktion passiert ist, wieder
als reverse undolog aufrufen und auf dem Weg sogar wie in einem Fall mal erforderlich
eine versehentlich gelöschte Baumstruktur mit weit mehr als 10000 Records in über 30
Tabellen wieder herstellen, nachdem wir im gleichen Log nachgesehen haben, mit welcher
Transaktionsnummer der verdächtige User das zu welcher Uhrzeit in etwa als delete befehl
im Redolog ausgelöst hat (obwohl da im Front end noch mehrere Sicherheitsabfragen kamen).
Wenn ich das richtig verstehe, könnte ich bei Interbase nun mit changeviews Tabellen
ganz oder teilweise deklarativ mit einem ähnlichen Protokoll ausstatten, nach meinem
Kenntnisstand wäre dann aber die 600GB Teil der production
db, weil Interbase das nicht
extern kann bzw execute stament on external auch mit blobs eh nicht kann.
Alles was wir da machen und wie wir das machen ist mit FB25 bordmitteln transaktionssicher
innerhalb der Datenbank also kombination von triggern und SPs umgesetzt, es ist also nicht
so das Firebird da vielleicht irgendwas nicht kann,
In einem meiner IBExpertise Video hatte ich das ja mal genauer gezeigt, falls jemand
weitere details braucht.
Zur ursprünglichen Frage: Ich glaub nicht annähernd das man mit change views in irgendeiner
weise 200 replizierte Datenbankstandorte in verschiedenen Städten organisieren kann, wie wir das
ja machen, aber vielelicht weiss ich darüber nur zu wenig. d.h. Replikation ist nun mal
was komplett anderes, change views machen aus meiner sicht logging
Und zur anderen Frage: Incremental Backup? geht, brauch ich aber nicht und will ich auch gar
nicht machen müssen, liegt aber eben auch daran, das wir nicht eine Datenbank als großen Mülleimer
für alles benutzen, sondern schon zeitnah prüfen wie man die Inhalten automatisiert
mit Bordmitteln verteilt speichern kann, ohne das der Programmierer da wirklich was
am Front End dazu umbauen muss.