Problem mit Datenbankverzeichnis

genau das habe ich heute morgen dann mit dem backup von freitag versucht
scheint auch alles zu gehen … naja bis auf die tatsache das er meckert das die pg_**** tabellen schon existieren
wieso überschreibt der nicht einfach alle daten?

hab das backup mit einem

psql [I]dbname[/I] < [I]infile[/I]

eingelesen (wo ist eigentlich der Unterschied zu pg_restore -d newdb db.tar?)

so ganz geheuer ist mir die backupgeschichte noch nicht da die handhabung mir nicht so verständlich ist wie z.b. in mysql

Schade auch das es keine direkte Möglichkeit gibt das Backup File zu zippen.

Warum sollte er? Ist doch offensichtlich ein Layer 8 - Problem.

hab das backup mit einem

psql dbname < infile

>
> _eingelesen_ > (wo ist eigentlich der Unterschied zu pg_restore -d newdb db.tar?)

Erster Satz aus der man-Page von pg_restore:

```text
pg_restore  is a utility for restoring a PostgreSQL database from an archive created by pg_dump(1) in one of the non-plain-text formats.



so ganz geheuer ist mir die backupgeschichte noch nicht da die handhabung mir nicht so verständlich ist wie z.b. in mysql

Schade auch das es keine direkte Möglichkeit gibt das Backup File zu zippen.

man pg_dump, auf -F bzw. --format sowie -Z bzw. --compress achten.


Andreas

Warum sollte es die Daten überschreiben?
Die pg_* Tabellen enthalten Systeminformationen. Diese werden mit einem normalen Backup auch nicht gesichert.

Daher frage ich mich, was genau du dort sicherst und wiederherstellst.



hab das backup mit einem

psql dbname < infile

>
> _eingelesen_ > (wo ist eigentlich der Unterschied zu pg_restore -d newdb db.tar?)

Oh, nun, das beschreibt die Dokumentation sehr ausführlich.
Das eine ist ein SQL-Dump, das andere ein binäres Format.
\
<br>
> so ganz geheuer ist mir die backupgeschichte noch nicht da die handhabung mir nicht so verständlich ist wie z.b. in mysql

Was an pg_dump && psql ist kompliziert?
\
\
<br>
> Schade auch das es keine direkte Möglichkeit gibt das Backup File zu zippen.

Zip ist so ein komisches Windows-Format, das will man nicht, weil das ist proprietär. Du kannst die Ausgabe von pg_dump jederzeit auf STDOUT ausgeben lassen und dann direkt durch gzip oder bzip2 oder jeden anderen Packer schicken. Unter Unix jedenfalls.

ZIP (Dateiformat – Wikipedia)

Nun, dann steht ja in dem Wikipedia Artikel alles weitere drin, warum man dieses Format nicht für gestreamte Daten (also was aus einem Backup kommt) verwenden kann.



Du kannst die Ausgabe von pg_dump jederzeit auf STDOUT ausgeben lassen und dann direkt durch > gzip > oder > bzip2 > oder jeden anderen Packer schicken.

hmm … seltsam

Also, für symbiont, damit er (ist das richtig?) das auch versteht:

Du kannst die Daten von pg_dump aus STDOUT ausgeben lassen und durch einen Packer schicken der gestreamte Daten verarbeiten kann.

Zip gehört nicht zu den Datenformaten die mit gestreamten Daten arbeiten können, daher kann man an dieser Stelle auch kein ZIP-Format verwenden.

Jetzt sollte es auch der letzte hoffentlich begriffen haben …



Es bleibt dir natürlich jederzeit freigestellt, die erstellte Backupdatei nachträglich zu zippen.

das ist kein problem des formates, sondern des packers - ob der eingeben von std-in entgegen nimmt … außerdem war ja die frage, ob pg_dump nicht gleich komprimieren koennte - kann es ja … des dingens erzeugt uebrigends auch ein zip format …

[nachtrag] ach ja … auch unter windows cmd kann man Std.IO verbiegen oder mit pipes arbeiten … wenn auch (vielleicht) nicht ganz so elegant wie unter den unix shells …

Nein.


Andreas

Doch - aber nicht immer - und nur wenn man moechte :slight_smile:

–compress=0…9 Specify the compression level to use. Zero means no compression. For the custom archive format, this specifies compression of individual table-data segments, and the default is to compress at a moderate level. For plain text output, setting a nonzero compression level causes the entire output file to be compressed, as though it had been fed through gzip; but the default is not to compress. The tar archive format currently does not support compression at all.

Use pg_dump’s custom dump format. If PostgreSQL was built on a system with the zlib compression library installed, the custom dump format will compress data as it writes it to the output file. This will produce dump file sizes similar to using gzip, but it has the added advantage that tables can be restored selectively. The following command dumps a database using the custom dump format:

zlib implementiert einen der unzaehligen kompressions-verfahren die man alle irgendwie als “zip” kennt … deflate halt

Du irrst. Wie so oft. zip != gzip, Punkt & EOD.

Andreas

möchtegern-klugscheisser lach … gzip basiert auf dem Deflate-Algorithmus, der eine Kombination aus LZ77

Zip ist allegemein die Bezeichnung von Komprimierungsverfahren zu der u.a. auch Deflate gehoert

was kann das Speicherformat zip dafuer, wenn gzip nur deflate kann

sicher - gzip ist nicht winzip und auch nicht pkzip … das war aber nicht das Thema

Seufz. Das klassische ZIP-Format ist nicht pipebar, das gzip-Format sehr wohl. Es war Deine Aussage, es würde das ZIP-Format verwendet werden, was definitiv falsch ist.

Hast Du es nun verstanden? Hörst Du eingentlich ganz und gar nicht das Gelächter aller hier über Dich?

Andreas

welches soll “das klassische Zip-Format” sein?

ach ja … die lachen entweder ueber dich - oder sind RTLII zuschauer

wenn du ueber shell prozesse daten austauschen laesst, geschieht das i.d.R entweder ueber std-io oder pipes … welches der beiden ist erstmal egal … am anderen ende (der empfaenger) kriegt also keine datei - sondern einen “stream” … der wird GENAU SO verarbeitet wie wenn der packer ne datei oeffnet … der empfaenger darf z.B. die ganze datei empfangen und “am ende” loslegen … oder blockweise (so wie sie alle arbeiten) und mit den bloecken die codierungs-tabellen aufbauen …

Ob ein packer sowas kann oder nicht - liegt am packer - nicht am verfahren … der packer darf z.B. sein ergebnis auch einfach in den muelleimer ausgeben …

aber von sowas versteht man nix - wenn man den ganzen tag nur an pg-configs zumschraubt

ach ja … ein “stream” ist auch nichts sonderbares … das ist einfach irgendeine datenquelle die mir mindestens die moeglichkeit gibt “vorwärts” zu seeken … packer oeffnen dateien i.d.r. auf die gleiche weise … fuettern das verfahren also auch mit einem “stream” … niemand kommt heute noch auf die idee fuer solche zwecke dateien zu puffern …

Das rauszufinden überlasse ich Dir. Wikipedia kennst Du ja.

Andreas

Vertauschte Reihenfolge. Deflate ist einer von mehreren möglichen Packalgorithmen für Zip, welcher auch in der zlib Verwendung findet.
Das bedeutet im Umkehrschluß nicht das man das ZIP-Containerformat direkt für gestreamte Daten einsetzen kann.

Nochmal … im Stream kommt kein “Format” an … da kommen zu packende rohdaten (ungepackt) an …

ZIP als Format ist - wie du sagst - ein container der die gepackten Daten organisieren soll - um den Kram in einer datei abzulegen - man will ja u.U. noch andere informationen unterbringen usw. Dateien sehen halt nicht irgendwie aus …

Aber genau DAS spielt hier - bei der prozess-kommunikation ueber pipes oder std-io absolut keine rolle … da gibts kein “ZIP” … nur ein rohen unkodierten stream - das dump halt

es obliegt jedem einzelnen pack-programm den entgegen zu nehmen und zu verarbeiten … oder es zu lassen … hat mit zip nix zu tun …

z.B. kann man rar dazu animieren daten von der standard-eingabe zu lesen und zu packen … und - OH WEH … in ein zip-format auszugeben

eiei

Man kann rar dazu animieren? Anscheinend nicht mein rar, das verlangt immer nach Dateien.

Und selbst wenn dem so ist, ich führe mal den Bogen langsam auf das Ausgangsproblem zurück: der Threadstarter wollte das Backup als Zip haben. Das Zip Format (wie im Wikipedia Link von symbiont auch beschrieben) ist ein Containerformat, welches Dateien zusammenfasst. pg_dump kann in Dateien schreiben und man packt diese in einem zweiten - unabhängigen - Schritt mit Zip. Eine direkte pg_dump Ausgabe schreibt jedoch keine Dateien sondern nur einen Datenstream. Wenn rar diese Daten jetzt in eine Datei packt und als Zip hinterlegt, ist das schön. Ist aber letztendlich nur ein Workaround für das, was der Threadposter ursprünglich wollte.

Und um symbiont glück zu stellen: pg_dump kann kein direktes Zip-Format schreiben. So eine blöde Datenbank aber auch, da sind die Entwickler wieder völlig weltfremd.

für windows-benutzer beliebtes winrar hat ein kommandozeilen-werkzeug bei - nennt sich rar … und das hat eine option
-si

die sorgt dafuer, dass daten von std-in entgegen genommen werden …
mit anderen parametern kannst du (was rar schon fast immer konnte) eine zip dateie ausgeben lassen …

koennte er z.B. erreichen indem er die ausgabe vom pg_dump nach std.in von rar umleitet :slight_smile:

siehe oben …

Nur das war eben NICHT das Thema … du hast behauptet es ginge nicht, weil das ZIP-Format keine “Streams aufnehmen” koenne …

was hinten und vorne bloedsinn ist … weil das eine mit dem anderen nichts zu tun hat …

  1. ist das abhaengig vom packer und nicht vom container-format und nicht von der datenbank und auch nicht vom wetter
  2. hat das auch nichts mit dem ausgabe-ziel von pg.dump zu tun - da kommt ein datenstrom raus … den kannst du dir hinstopfen wo du willst :slight_smile: - geschickter weise eben in einen packer … man koennte den wahrscheinlich acuh einem pg_restore unterschieben und gleich in eine ander DB leiten …
  3. siehe oben