Letztes backup/restore datum

[MyRealName]

Hallo,

Kunden machen ja nie etwas falsch und so... Ich habe oftmals das Problem, dass ein Kunde sagt : es funktioniert dies oder jenes nicht und wenn ich dann mir die Datenbank ansehe, dann hat doiese Schäden wie kaputte Indexe oder pages etc. nach einem Backu/Restore geht es dann wieder. Da der Admin der Firma das regelmässig machen sollte, frage ich natürlich nach und es ist immer "vor ein paar Tagen" gewesen, zum Bsp. "letzten Freitag".

Gibt es eine Möglichkeit zu sehen, wann das letzte Backup/Restore war ?

Danke :)

[Delphi.Narium]

Suchst Du hiernach? https://firebirdsql.org/manual/nback...uphistory.html

Wird gefüllt, wenn die firebirdeigene nbackup.exe genutzt wird.

[hoika]

Hallo,
Backup/Restore selber machen (gbak-Aufrufe) und das Datum des Restores in eine eigene Tabelle in die DB schreiben.

[MyRealName]

Zitat:

Zitat von Delphi.Narium (Beitrag 1398124)

Suchst Du hiernach? https://firebirdsql.org/manual/nback...uphistory.html

Wird gefüllt, wenn die firebirdeigene nbackup.exe genutzt wird.

"The contents of the table RDB$BACKUP_HISTORY are not backed up and restored by gbak; see the section Technical background information for details."

Leider hilft das nichts :(

Gibt es keine DB Info die man lesen kann, wann die DB erzeugt wurde zum bsp ?

[blawen]

Zitat:

Zitat von MyRealName (Beitrag 1398121)

Hallo,

Kunden machen ja nie etwas falsch und so... Ich habe oftmals das Problem, dass ein Kunde sagt : es funktioniert dies oder jenes nicht und wenn ich dann mir die Datenbank ansehe, dann hat doiese Schäden wie kaputte Indexe oder pages etc. nach einem Backu/Restore geht es dann wieder. Da der Admin der Firma das regelmässig machen sollte, frage ich natürlich nach und es ist immer "vor ein paar Tagen" gewesen, zum Bsp. "letzten Freitag".

Gibt es eine Möglichkeit zu sehen, wann das letzte Backup/Restore war ?

Danke :)

Ich pers. habe es so gelöst, dass mein Programm bei zwei definierten Benutzern alle 20 Minuten automatisch ein Backup der DB erstellt und die Datei jeweils gleich zippt.
Somit habe ich im Normalfall bis zu 6 Backups/Stunde ohne, dass ich mich auf die IT-Abteilung verlassen muss. Da ich in meinem Fall keine Bilder, etc. in der DB hoste, sind die ZIP-Dateien je nach Anwendung ein paar hundert KB, bzw. wenige MB gross.

[Lemmy]

Zitat:

Zitat von MyRealName (Beitrag 1398135)

Gibt es keine DB Info die man lesen kann, wann die DB erzeugt wurde zum bsp ?

nicht dass ich wüsste. Was würde dir das im übrigen bringen? Du willst doch wissen, wann das letzte Backup gemacht wurde?

Ich mach es inzwischen wie Heiko schon geschrieben hat, schon allein um die Kunden zu nerven die das Backup mal wieder abgeschaltet haben, weil das immer so lange dauert... Einfach in eine Tabelle schreiben und gut ist. Und für die IT Abteilung ein "eigenes" gbak implementieren, das die per Kommandozeile aufrufen können, das die Aufgabe die Info in die Tabelle zu schreiben übernimmt.

[KodeZwerg]

Würde nicht auch ein Check der Datei-Attribute (File Creation Time usw.) ausreichen?

[MyRealName]

ich kann leider nicht ständig ein backup machen, wir haben Kunden-DBs mit 5+ GBs
Ich denke, im Endeffekt werde ein backup/restore + Mend schreiben, welches das selbst in die Hand nimmt, man kann den Kunden einfach nicht vertrauen

[ibp]

Zitat:

Zitat von MyRealName (Beitrag 1398146)

ich kann leider nicht ständig ein backup machen,....

es gibt doch in Windows den Taskplaner...Backup von dem nach vorgegebenen Zeiten erstellen lassen und in den Dateinamen Datum und Uhrzeit packen..."meineDB_201804050913.fbk"

[Delphi.Narium]

Warum nicht statt gbak das zu FireBird gehörende nBackup nutzen? Das schreibt das Sicherungsdatum in die Datenbank.

[MyRealName]

ich kann leider nie davon ausgehen, dass ich Zugang zur Firebird-installation habe. Mein Programm ist ein Service, welches die Datenbanken und den Zugang der Kunden mit den Lizenzen für 1-n Firmen handhabt. Die Datenbanken sind oftmals im gleichen Server, aber auch auf anderen (wenn der Kunde zum Bsp. Linux für die DBs bevorzugt. Oder einfach AppServer und DbServer getrennt handhaben will.

Deswegen nutze ich für Backup im Moment IbDAC. Das ist aber im Moment nur für eine Funktion für den Support (Backup machen, das komprimieren als zip und dann auf unseren Firmenserver hochladen).

[KodeZwerg]

Was spricht denn dagegen sich das Datei-Attribut zunutze zu machen? (Last Time Modified usw.)

[hoika]

Hallo,
der letzte Zugriff auf die DB muss doch nicht die Backup-/ oder Restorezeit sein,
oder habe ich da was mißverstanden?

[MyRealName]

mal abgesheen davon, dass ich nicht unbedingt Zugriff auf die Datei selbst habe, das Modified Datum ist ja immer aktualisiert bei jedem Commit.

[ibp]

also du startest aus deinem Programm heraus über IBDac ein Backup oder Restore, dann logge das doch einfach für dich selber mit. Dann kannst du auch automatisiert dein Programm nachschauen lassen, z.b. beim Start, wann das letzte Backup war und nach einer definierten Zeitspanne (Minuten, Stunden, Tage, Wochen, Monate, Jahre) einfach ein neues Backup starten lassen. Wenn es erwartend länger dauert einfach ein Info-Fenster, damit der User weiß, dass es um seine Datensicherheit geht - fertig.

[jobo]

Ich verstehe die Vorschläge hier nicht, wie kann man eigenmächtig, willkürlich ein Backup einer DB mit einem Volumen von 5GB starten?
Ich habe keine Lösung, aber hoffe, es findet sich etwas smarteres.

[KodeZwerg]

Zitat:

Zitat von MyRealName (Beitrag 1398121)

Gibt es eine Möglichkeit zu sehen, wann das letzte Backup/Restore war ?
.....mal abgesheen davon, dass ich nicht unbedingt Zugriff auf die Datei selbst habe.....

Modified Stempel sollte ja vom Backup ausgewertet werden worauf du keinen Zugriff hast aber Backups Steuern willst, irgendwie beisst sich hier die Katze in den Eigenen Schwanz.
Tjo, damit bin ich raus. Viel Erfolg!

[mkinzler]

Backup das bisher vom Kunden manuell durchgeführt wurde ist nicht mit dem automatischen Backup aus dem Programm heraus gleichzusetzen

[MyRealName]

Ok, scheinbar gibt es einen Solchen Wert ind er Datenbank nicht zum auslesen. Ich hatte gehofft, sowas wie die OSD Version etc, die man ja auslesen kann, dass da vllt. auch eine Info steht, wann die DB erzeugt wurde (über script oder restore oder was auch immer).

Klar kann ich mir die Funktionen schreiben um nachts ein backup/restore zu machen, aber es existrioert noch nicht und ich hatte jetzt das Problem, dass die KundenDb beschädigt ist und der Kunde mir IMHO quatsch erzählt. Das hat dann nämlich auch was mit Support-Stunden-Abrechnung zu tun.

Aber danke an alle, die sich an der Diskussion beteiligt haben.

[KodeZwerg]

Workaround eventuell:
In deinem Programm, was der Anwender steuert, wenn der Anwender da auf "Backup" Knopf drückt, könnte da nicht auch ein Registrierungs oder Ini oder Text Datei Eintrag erfolgen, ebenso für Knopf "Restore" (falls überhaupt Notwendig)?
Dann hättest Du zwei Werte die Du verarbeiten könntest und eventuell eine visuelle Darstellung basierend darauf wie "Letztes Backup am/um" oder "Achtung: Letztes Backup bereits X Minuten/Stunden/Tage her!" oder völlig Silent nur per Log-Datei.
So wärst Du Unabhängig von DB-Code, was Du ja vermeiden wolltest.

[jobo]

Das klingt eher nach einem Punkt, wo man im Sinne von Professionalität ein Schleife über seine Supportleistungen und deren Bedingungen drehen sollte.
Wenn es Programme gibt (eins?), die einen Backupstempel schreiben, muss man evtl. deren Einsatz verlangen. Andernfalls gibt es nur Support nach Aufwand.

Außerdem denke ich, solche "Effekte" sollten auch die Opensource Anbieter in ihre Entwicklung einbeziehen. Bei closed source Systemen und entsprechenden Wartungsverträgen ist es relativ einfach, hier klare Kante zu fahren. Solche Features entscheiden m.E. am Ende auch über Erfolg und Einsatzbreite eines Systems.

[mkinzler]

Man könnte sich überlegen, in das Programm eine Backupfunktion einzubauen, die neben dem Backup der Datenbank noch andere Sachen sichert. Diese Funktion (bzw. die Verwendung) wäre dann verpflichtent und entscheidend bei einem Supportfall. Man könnte dann auch im Programm auf "fehlende" Backups hinweisen.

[MyRealName]

Zum Verständnis :

Ich will natürlich schon länger eine Funktion, wo nicht nur regelmässig ein backup gemacht wird, sondern es auch kostenpflichtig zur Sicherung auf unserem Firmenserver hochgeladen werden kann, um zum Bsp. die letzten 7 oder 30 Tage als Kopien zur Sicherheit da zu haben.

Bei dem Backup/Restore geht es natürlich darum, eventuell Index- oder Seitenfehler der Datenbank sicher zu beheben, von daher soll natürlich nicht nur ein Backup gemacht werden, sondern auch ein Restore, um darin weiter zu arbeiten. Nur ein backup bringt da natürlich nichts, da ich in derselben Datei weiterarbeite und die Fehler sich nur verschlimmern :p

[jobo]

Das Anliegen bzw. das Ziel der Backup "Erkennung" war denke ich schon relativ klar.
Diese Backuperkennung wäre also auch nur die halbe Miete. Man müsste dann zusätzlich ein Restore feststellen, vielleicht reicht auch das Letztere.
Vielleicht kann man es auch andersrum sinnvoll für den akuten Zweck sein, eigenständig eine Prüffunktion anzustoßen, die Index oder Seitenfehler wenigstens findet. Es reicht ja schon auf Existenz zu prüfen.
Damit spart man sich den Datenverkehr und ist dennoch aussagefähig bzw. kann es im notfalls on demand aufrufen.
Ich weiß nicht, ob fb die reine Erkennung bietet ohne ein backup/restore wirklich durchzuführen.

[Delphi.Narium]

Zu Jobos Idee aus der Doku von FireBird:

Code:

fbsvcmgr [host:]service_mgr [user <...>] [password <...>]
   action_validate dbname <filename>
   [val_tab_incl <pattern>]
   [val_tab_excl <pattern>]
   [val_idx_incl <pattern>]
   [val_idx_excl <pattern>]
   [val_lock_timeout <number>] 

where
   val_tab_incl      pattern for tables names to include in validation run
   val_tab_excl      pattern for tables names to exclude from validation run
   val_idx_incl       pattern for indices names to include in validation run, 
                  by default %, i.e. all indices
   val_idx_excl      pattern for indices names to exclude from validation run
   val_lock_timeout    lock timeout, used to acquire locks for table to validate,
                  in seconds, default is 10 sec
                   0 is no-wait
                  -1 is infinite wait

siehe README.online_validation.txt im Verzeichnis doc zu FireBird.

Man müsste hier dann die Konsolenausgabe abfangen/in Datei umleiten, um das Ergebnis auszuwerten.

Oder sporadisch laufen lassen und die Ergebnisse per Mail schicken lassen. Dann kann man zumindest zum Kunden sagen: "Schau mal bitte nach, Deine DB geht kaputt ;-)"

[MyRealName]

Ich denke, IbDAC hat da eine Komponente dazu. Das ist aber eine gute Idee :)

[tsteinmaurer]

Zitat:

Ich hatte gehofft, sowas wie die OSD Version etc, die man ja auslesen kann, dass da vllt. auch eine Info steht, wann die DB erzeugt wurde (über script oder restore oder was auch immer).

"Creation Date" steht in der Header Page der Datenbank, z.b. mit "gstat -h ..." oder mit Komponenten (IBDAC) deines Vertrauens abrufbar.

Siehe z.B.: https://www.firebirdsql.org/pdfmanua...le-header.html

[MyRealName]

Sowas habe ich gesucht, danke!