Firebird Backup/Restore mit FIBPlus

[Chemiker]

Hallo,

bei FIBPlus gibt’s die Komponenten pFIBBackupService und pFIBRestoreService gibt es irgendwo ein gutes Beispiel wie man sie einsetzen kann?

Bis bald Chemiker

[Hansa]

So ungefähr :

Delphi-Quellcode:

procedure TfrmSicherung.btnSicherungClick(Sender: TObject);
begin
  inherited;
  SchreibeJournal ('Datensicherung gestartet');
  StatusMemo.Show;
  StatusMemo.Lines.Clear;
  with BackupService do begin
//    ServerName := 'localhost';
    LoginPrompt := False;
    Params.Add('user_name='+User);
    Params.Add('password='+Password);
    Active := True;
    try
      Verbose := True;
      // You can set here any your necessary options
      Options := [NonTransportable, IgnoreLimbo];
      DatabaseName := DBgdb;
      BackupFile.Clear;
      BackupFile.Add(DBgbk);
      ServiceStart;
    finally
      Active := False;
      ShowMessage ('lokale Datensicherung beendet !'+#10#13+'Die Datei '+
                     ExtractFilePath (ParamStr (0))+'DB\DB.FBK'+
                    ' sollte aber noch auf ein externes Medium kopiert werden!');
      SchreibeJournal ('Datensicherung beendet');
      Close;
    end;
  end;
end;

procedure TfrmSicherung.FormCreate(Sender: TObject);
begin
  inherited;
  DBgdb    := ExtractFilePath (ParamStr (0))+'DB\DB.FDB';
  DBgbk    := ExtractFilePath (ParamStr (0))+'DB\DB.FBK';
  User     := 'SYSDBA';
  Password := 'masterkey';
end;

Delphi-Quellcode:

inherited frmSicherung: TfrmSicherung
  Left = 408
  Top = 263
  Width = 491
  Height = 423
  Caption = 'Systemsteuerung'
  PixelsPerInch = 96
  TextHeight = 16
  object Label1: TLabel [1]
    Left = 16
    Top = 8
    Width = 128
    Height = 20
    Caption = 'Datensicherung'
    Font.Charset = DEFAULT_CHARSET
    Font.Color = clBlue
    Font.Height = -16
    Font.Name = 'MS Sans Serif'
    Font.Style = [fsBold]
    ParentFont = False
  end
  inherited sbDrucker: TStatusBar
    Top = 377
    Width = 483
  end
  inherited pnlEscEnde: TGfghPanel
    TabOrder = 3
  end
  object StatusMemo: TMemo
    Left = 16
    Top = 88
    Width = 457
    Height = 241
    Font.Charset = DEFAULT_CHARSET
    Font.Color = clWindowText
    Font.Height = -11
    Font.Name = 'MS Sans Serif'
    Font.Style = []
    ParentFont = False
    ScrollBars = ssBoth
    TabOrder = 1
    Visible = False
  end
  object btnSicherung: TButton
    Left = 16
    Top = 40
    Width = 75
    Height = 25
    Caption = 'Start'
    TabOrder = 2
    OnClick = btnSicherungClick
  end
  object BackupService: TpFIBBackupService
    OnTextNotify = BackupServiceTextNotify
    BlockingFactor = 0
    Options = []
    Left = 440
    Top = 344
  end
end

[Chemiker]

Hallo,

wenn ich über diese Komponenten das Backup und das Restore durchführe, dürfen die Clients keinen Zugriff auf die Datenbank haben, aber wie sieht mit dem Server von Firebird aus muss er vorher runtergefahren werden?

Bis bald Chemiker

[TBx]

Wieso dürfen die Clients keinen Zugriff auf die Datenbank haben?
Diesen dürfen Sie immer über den Server haben. Auch bei der Datensicherung. Diese ist wie alles andere im Firebird auch transakionsgestützt. Das bedeutet, dass alles, was noch nicht gepostet ist, eben auch nicht gesichert wird.

Und der Server muss den Zugriff sowieso haben, dieser führt die Datensicherung aus!

Beim Restore ist es richtig, da dürfen die Clients keinen Zugriff haben.

Dies kannst DU auf mehrere Arten Erreichen, zu.B. kannst Du die Datenbank zuvor herunterfahren (bringt aber nur was, wenn nicht wie so oft nur auf SYSDBA gearbeitet wird).
Ein anderer gängiger Weg ist es, die DB mit einem anderen Namen zu restoren und dannach umzubenennen.

Gruß

Thomas

[Chemiker]

Hallo,

Danke erst mal.

Zusammenfassung:

1. Der Server muss bei Restore und beim Backup laufen.
2. Ein Backup ist auch bei Client zugriff möglich
3. Beim Restore dürfen die Client keinen Zugriff haben.

Zum Punkt 3 stellt sich nur die Frage, wie kann ich gewährleisten das die Clients keinen Zugriff haben, wenn das Restore läuft?

Wenn möglich, würde ich gerne eine Applikation dafür Schreiben, dass das Restore automatisch durchgeführt wird und zuvor die Clients gesperrt werden. Ist das überhaupt möglich und wenn ja, wie kann man das Umsetzen?

Bis bald Chemiker

[dataspider]

Hi,

Man sollte vor dem Backup die DB herunterfahren (ConfigService / ShutDownDataBase).
Jetzt darf nur noch der Besitzer der DB sich anmelden.
Firebird blockt normalerweise alle Benutzer ausser SYSDBA.
Im Backupprozeß[EDIT]Restore, nicht Backup[/EDIT] wird IMHO dann auch zusätzlich SYSDBA geblockt.
Als Errorcode erhält man beim Connectversuch 335544528 (isc_shutdown).
Somit sollte man auf diesen Fehler entsprechend reagieren.

Frank

[borwin]

Hallo Chemiker,

Zitat:

Zum Punkt 3 stellt sich nur die Frage, wie kann ich gewährleisten das die Clients keinen Zugriff haben, wenn das Restore läuft?

also grundsätzlich machst Du nur ein Restore, wenn mal was schief gegeangen ist. D.h. die Datenbank oder der Server ist gecrash.
Dann können die clients sowieso nicht arbeiten.
Beim Restore wird die Datenbank neu angelegt. Die alte wird nicht überschrieben. Diese wird vorher gelöscht.
Während des Restore kann sowieso kein Client auf die Datenbank zugreifen.
Somit sehe ich die Sache sehr unkritisch.

Gruß Borwin

[TBx]

Zitat:

Zitat von borwin

also grundsätzlich machst Du nur ein Restore, wenn mal was schief gegeangen ist.

Von diesem Vorgehen ist dringend abzuraten.
Ein erfolgreiches Backup ist noch lange keine Garantie für ein erfolgreiches Restore.
Man sollte nach einem Backup immer auch ein Restore durchführen, nicht ins laufende System sondern an einem seperaten Ort. Sollten dabei Fehler auftreten, hat man noch die Möglichkeit zu reagieren.
Im Fehlerfall nicht reagieren zu können, weil man auch ein Backup hat, das nicht wiederherstellbar ist, wäre ja nun wirklich nicht schön.

[borwin]

Zitat:

Man sollte nach einem Backup immer auch ein Restore durchführen, nicht ins laufende System sondern an einem seperaten Ort.

Da stimme ich Dir 100% zu. Dort gibt es aber keine Probleme mit den Clients.

Gruß Borwin

[Chemiker]

Hallo,

vielen Dank für die vielen Ideen und Anregungen.

Ich habe jetzt mir ein Testtool mit FIBPlus zusammengeschrieben und auch schon getestet. Habe mal aus der Datenbank 2 Mio. Datensätze gelöscht zu Testzwecken.
Backup gezogen geht auch mit angemeldeten Client, aber die Performanz leidet aber merklich darunter. Beim Restore zuvor den Client abgemeldet (Anwendung runtergefahren) und anschließend mit dem Testtool das Restore durchgeführt (Das braucht aber auch seine Zeit bei 40 Mio. Datensätze).
Danach war die DB erheblich verkleinert und die Geschwindigkeit der Datenbank war angestiegen.

Zitat:

Zitat von TBx

Man sollte nach einem Backup immer auch ein Restore durchführen, nicht ins laufende System sondern an einem seperaten Ort. Sollten dabei Fehler auftreten, hat man noch die Möglichkeit zu reagieren.

Wie würde man so was organisatorisch und technisch umsetzen?

Postulieren wir mal, es wird ein Backup gezogen und der Test ob das Backup i.o. ist wird auf eine andere Weise getestet (nicht im laufenden System), wie kann man dann die DB „reinigen“ sprich gelöschte Datensätze tatsächlich löschen, nicht abgeschlossene Transaktionen schließen usw. und das am liebsten beim laufenden System?

Bis bald Chemiker

[mkinzler]

Zitat:

wie kann man dann die DB „reinigen“ sprich gelöschte Datensätze tatsächlich löschen, nicht abgeschlossene Transaktionen schließen usw. und das am liebsten beim laufenden System?

Mit einem Sweep
Ein Backup/Restore Zyklus ist allerdings die effektivste Lösung

[mquadrat]

@mkinzler

IMHO schließt ein Sweep aber keine offenen Transaktionen. Die müssen erst zu sonst läuft der Sweep ins Leere..

[mkinzler]

Ja deshalb ist ein Backup/Restore ja am effektivsten

[hoika]

Hallo,

Zitat:

Wie würde man so was organisatorisch und technisch umsetzen?

Also ich restore immer in eine restore.fdb (data.fdb -> data.fbk -> restore.fdb).

Ein einfacher Test, ob alles gutgegangen ist,
wäre ein select count (*) über alle Tabellen, dann Backup, dann Restore,
Connect zur Restore, Select Count(*) und prüfen,
ob alle Datensätze drinstehen.

Das
select count (*) über alle Tabellen, dann Backup,
in der gleichen Transaktion laufen lassen.

Wenn das Backup also Dienst (-service) läuft,
sollte der Rechner nicht in die Knieh gehen ;)
Auch sollte man das verbose (habe nur die Komamndzeilen-Params im Kopf)
weglassen.


Heiko

[Freiwilderer]

moin,
ich hab das mal ausprobiert und das programm spuckt zwar aus, dass es durchgelaufen ist, aber die neue Sicherungsdatei ist nicht erstellt worden ...

nutze Delhpi 5 ^^

würde mich über einen Lösungsvorschlag freuen

[Freiwilderer]

scheint wohl irgendwie am passwort zu liegen, hab jetzt diese fehlermeldung bekommen.

........
Unsuccessful exception caused by a system error that procludes
successful execution of subsequent statements.
Your user name and password are not defined. Ask your databas administrator ......... und so weiter.

habe aber die parameterübergabe drin

Delphi-Quellcode:

    LoginPrompt := False;
    Params.Add('user_name='+User);
    Params.Add('password='+Password);
    Active := True;

mfg

[Freiwilderer]

hi,
... hab nen fehler gefunden und jetzt erstellt er eine fbk datei, allerdings hat die nur 60kb (bei einer ausgangsdateigröße der db von ca 40mb) er scheint da also irgendwo abzubrechen, kommt allerdings kein fehler, in dem debugger auch nich ^^

mfg

[Chemiker]

Hallo Freiwilderer,

tut mir leid das ich jetzt erst jetzt Zeit gefunden habe Dir zu antworten, bin zur Zeit dabei mich in C# einzuarbeiten.

Das die Datei kleiner wird ist ja durchaus möglich, weil die Datenbank ja aufgeräumt wird und die Datensätze die gelöscht sind auch tatsächlich gelöscht werden. Ob die ganze Aktion funktioniert hat, kann man ja sehen wenn man nach dem BackUp ein Restore durchführt.

Ich habe mir ein kleines Programm geschrieben und mit den beiden Befehlen etwas zu spielen, was allerdings noch nicht eingearbeitet worden ist, ist der automatische Test ob das Backup auf in alle Einzelheiten auch richtig durchgeführt worden ist.

So sieht der Quelltext für das Backup aus:

Delphi-Quellcode:

procedure TForm3.btAktionAusfuehrenClick(Sender: TObject);
begin
  with pFIBBackupService1 do
  begin 
    BackupFile.Clear;
    Params.Clear;
    ServerName:= 'localhost';
    LoginPrompt:= FALSE;
    Params.Add('user_name=sysdba');
    Params.Add('password=masterkey');
    Active:= TRUE;
    try
      Verbose := True;
      Options:= [IgnoreLimbo,NonTransportable];    
      DatabaseName:= FFBDBOriginal;
      BackupFile.Add(FFBDBCopy);
      ServiceStart;
      while not EOF do
      begin
        MemoAktionenAnzeigen.Lines.Add(GETNextLine);
      end;
    finally
      Active:= FALSE;
    end;    
  end;
end;

Und so für das Restore:

Delphi-Quellcode:

procedure TForm3.Button3Click(Sender: TObject);
begin
  with pFIBRestoreService1 do
  begin
    ServerName:= 'localhost';
    LoginPrompt:= FALSE;
    Params.Add('user_name=sysdba');
    Params.Add('password=masterkey');
    Active:= TRUE;
    try
      Verbose := True;
      Options := [Replace, UseAllSpace];
      PageBuffers := 3000;
      PageSize := 4096;
      BackupFile.Add(FFBDBCopy);
      DatabaseName.Add(FFBDBOriginal);
      ServiceStart;
      while not EOF do
      begin
        MemoAktionenAnzeigen.Lines.Add(GETNextLine);
      end;
    finally
      Active := False;
    end;
  end;
end;

Soweit funktioniert das auch, aber bitte nicht mit der original Datenbank durchführen sonder eine Test Datenbank anlegen und selber testen. In der Hilfe von FIBPlus ist auch einiges beschrieben, man muss leider sich das nur mühselig zusammensuchen.

Bis bald Chemiker

[Freiwilderer]

hi chemiker,
danke für deine Antwort.

läuft so irgendwie immer noch nicht
also meine Ursprungsdatenbank hat 36MB
wenn ich die dann gesichert habe sind es noch 61KB (was ich für ziemlich klein halte)
nach einem restore, den ich gerade ausprobiert habe, hat die DB dann eine größe von ca 1MB

hab die while not eof schleife rausgenommen, weil die ja wohl eh nur zum protokollieren is, sonst aber alles so weit übernommen.

hier nochmal meine backupprocedure, vielleicht sieht da jemand noch n fehler...:

Delphi-Quellcode:

procedure TfrmDatensicherung.BT_StartClick(Sender: TObject);
begin
  with FIB_Backup do
  begin
    BackupFile.Clear;
    Params.Clear;
    if Pos('/3050:',ED_DBPfad.Text) > 0 then  // Lokaler oder UNC Pfad?
     begin
      DatabaseName := Copy(ED_DBPfad.Text,Pos('/3050:',ED_DBPfad.Text)+6,Length(ED_DBPfad.Text));
      ServerName   := Copy(ED_DBPfad.Text,1,Pos('/3050:',ED_DBPfad.Text)+4);
      Protocol     := TCP;
     end
    else
     begin
      ServerName:= 'localhost';
      DatabaseName := ED_DBPfad.Text;
      Protocol := Local;
     end;

    LoginPrompt:= FALSE;
    Params.Add('user_name=sysdba');
    Params.Add('password=masterkey');
    Active:= TRUE;
    try
      Verbose := True;
      Options:= [IgnoreLimbo,NonTransportable];
      BackupFile.Add(ED_Sicherungspfad.Text);
      ServiceStart;
    finally
      Active:= FALSE;
    end;
  end;
end;

mfg

[Freiwilderer]

KOMANDO: ZURÜCK

... ... die wiederhergestellte datenbank, ... die mit etwas über ein MB läuft
...
das heißt, wohl, dass ich mich einfach mit der größe vertan hab ^^
aber ne DB Sicherung, mit 61KB is ja schon echt sehr klein ^^

is halt noch nich so viel drin ... wäre aber nie auf die idee gekommen, dass das richtig sein könnte ;)

vielen dank für die hilfe.

[Chemiker]

Hallo,

ich möchte das Thema nochmal aufgreifen.

Ein Backup wird während des laufenden Betriebes des FB-Servers durchgeführt. Das ist ja dann eine Momentaufnahme der DB zum Beginn des Backups. Jetzt läuft das Backup in der Zwischenzeit werden aber weitere Datensätze in die DB geschrieben (Im konkreten Fall ca. 200 pro Minute).

Nach dem Backup wird ein Restore durchgeführt mit einem anderen DB-Name, anschließend getestet ob das Backup i.O. ist. Das Restore ist O.K. nun wird das Restore umbenannt und zur Arbeits-DB.

Das ganze dauert natürlich einige Zeit, dadurch werden die Datensätze nicht erfasst die während dieser Manipulationen anfallen.

Wie kann man das Verhindern, oder zumindest minimieren?

Bis bald Chemiker

[Lemmy]

Hi,

weshalb willst Du ein Backup/Restore machen und das Restore anschließend als ArbeitsDB weiter verwenden?

Den Datenverlust kannst Du nur dadurch minimieren, indem Du alle Clients vorher von der DB trennst.
Grüße

Edit: Möglichkeit: Die CLients kommunizieren nicht direkt mit der DB sondern über einen eigenen App-Server, der die Daten "zwischenspeichert" und nach dem REstore in die DB schreibt...

[Chemiker]

Hallo Lemmy,

Zitat:

Zitat von Lemmy

Möglichkeit: Die CLients kommunizieren nicht direkt mit der DB sondern über einen eigenen App-Server, der die Daten "zwischenspeichert" und nach dem REstore in die DB schreibt...

es ist eigentlich nur ein Client ständig mit der DB verbunden (es geht um Messdatenerfassung) die anderen kann ich schließen. Es müsste ja eigentlich so gehen, dass ich vor dem BackUp ein Flag setzen das keine Datensätze mehr in die DB geschrieben werden können und die Datensäte einfach in ein Clientdataset schreibe, bis die DB wieder zur Verfügung steht. Anschließend die Datensätze aus dem Clientdataset auslesen und in die richtige DB schreiben. Danach die DB für alle wieder freigeben.

Bis bald Chemiker

[Hansa]

Zitat:

Zitat von Chemiker (Beitrag 1066058)

...Es müsste ja eigentlich so gehen, dass ich vor dem BackUp ein Flag setzen das keine Datensätze mehr in die DB geschrieben werden können...

Lege doch einfach irgendeinen Datensatz an bzw. lösche ihn wieder und überprüfe, ob der da ist oder nicht. Desweiteren würde ich mal SavePoints in betracht ziehen. Es gibt ja schliesslich auch Commit/RollbackToSavePoint etc.

[Lemmy]

Hi,

Zitat:

Zitat von Chemiker (Beitrag 1066058)

in ein Clientdataset schreibe, bis die DB wieder zur Verfügung steht. Anschließend die Datensätze aus dem Clientdataset auslesen und in die richtige DB schreiben. Danach die DB für alle wieder freigeben.

klar, das kannst Du natürlich auch machen. Per TCP/IP-Chat dem Client mitteilen, jetzt ist gut, mach die Transaktionen zu und wenn er das OK gibt, kannst Du ein Backup/Restore machen.

Musst halt schauen was passiert, wenn der Client abstirbt und die MEssdaten weg sind. Lokale DB (Firebird,SQLite,...) ggf. sinnvoller wenn es um ununterbrochene Messdaten geht....

GRüße