Datenbank Backup / Replikation

[PetraSteiner]

Hallo,
kann mich bitte jemand unterstützen und Infos liefern?

Ich habe als fiktives Beispiel ein Server im Internet stehen. Hier werden Daten gesammelt.

Mein Ziel: Ich möchte auf einem Rechner zuhause, z.B. einem Miniserver die Datenbank sichern.
Welche Möglichkeiten bieten sich für mich an?
Von der Theorie könnte ich nachts die Datenbank per Dump sichern und den Dump lokal wieder einspielen.
Mich würde jetzt interessieren ob eine Replikation für mich in Frage kommen könnte.
Leider habe ich damit null komm null Erfahrung. Müssen die Rechner z.B. immer in Kontakt stehen?

 

[akretschmer]

Hallo,
kann mich bitte jemand unterstützen und Infos liefern?

Ich habe als fiktives Beispiel ein Server im Internet stehen. Hier werden Daten gesammelt.

Mein Ziel: Ich möchte auf einem Rechner zuhause, z.B. einem Miniserver die Datenbank sichern.
Welche Möglichkeiten bieten sich für mich an?
Von der Theorie könnte ich nachts die Datenbank per Dump sichern und den Dump lokal wieder einspielen.

Wäre denkbar.

Mich würde jetzt interessieren ob eine Replikation für mich in Frage kommen könnte.
Leider habe ich damit null komm null Erfahrung. Müssen die Rechner z.B. immer in Kontakt stehen?

Replikation geht auch. Bedenke, daß bei einer normalen Streaming Replication der Standby ReadOnly ist. Bei einer Replikation kann es durchaus auch zu Unterbrechungen kommen, dies kann man durch geeignete Maßnahmen wie z.B. Replication Slots aber abfedern

Und ja: Replikation != Backup. Das sind 2 komplett verschiedene Dinge, und es wird grad nicht klar, was genau Du erreichen willst.


Andreas

 

[Dukel]

Was ist das Ziel auf dem Server zu hause?
Willst du das weiter nutzen? Als Backup, falls der Server im Internet ausfällt?

 

[Walter]

Replikation != Backup

Dazu nur ein Beispiel für @PetraSteiner:

Auf der Originaldatenbank löscht jemand versehentlich zuviele Datensätze. Diese Änderung wird per Replilkation sofort auf den Backup-Server übertragen, damit sind die Daten weg.

 

[akretschmer]

jein ... ich kenne auch Setups, wo es zeitversetzte Standbys gibt, mittels ``recovery_min_apply_delay``. Die sind also bewußt zeitversetzt in der Replikation, damit man bei solch 'menschlichen' Fehlern noch von solch einem zeitversetzten Standby schnell ein Backup der nötigen Daten machen kann. Kann bei Datenbanken im TB-Bereich durchaus eine sinnvolle Maßnahme sein. Aber generell hast Du Recht und genau daß hatte ich auch im Sinn.

 

[PetraSteiner]

Vielen Dank für die Feedbacks.
Ich möchte eigentlich die Daten auf meinem heimischen Rechner zur Weiterverarbeitung und als zweites Backup, das so aktuell ist wie möglich.
Auf dem eigentlichen Server wird 2x am Tag ein Dump gemacht. Aber jedesmal die Datenmenge ziehen....
Welche Fallstricke könnten mich da erwarten?

 

[akretschmer]

Auf dem eigentlichen Server wird 2x am Tag ein Dump gemacht. Aber jedesmal die Datenmenge ziehen....
Welche Fallstricke könnten mich da erwarten?

• Dump übertragen: Übertragungsmenge, kommt auf den Vertrag an
• Dump erstellen: in der Zeit bestehen gewisse Locks, da gehen also keine DDL-Änderungen, aber auch Autovacuum muß auf das Ende warten, bis es während des Dump gelöschte Records markieren kann. Das kann zu Bloat führen
• Last während der Dumperstellung
• Ein Dump ist nur ein Snapshot, Restore zum Zeitpunkt den Dump-Startes. Keine Chance für PITR