DB auf externen Medium

Es ist ja nicht im Sinne des Erfinders, die Fragen aus einem Forum privat zu klären.
Was genau ist daran schlimm?
Wenn jemand solche Leistungen unentgeltlich fordert kann ich es ja verstehen, dass es nicht gerne gesehen ist, aber ich möchte diese Leistung ja angemessen bezahlen.
Wenn es darum geht, anderen an der Lösung des Problems teilhaben zu lassen, kann man ja den Weg der letztendlich zur Lösung geführt hat hier preisgeben.

Ich werde es dennoch morgen oder die nächsten Tage mal versuchen, befürchte aber, es nicht direkt zu schaffen und hier einige eher blöde Fragen stellen zu müssen.
Worauf muss ich denn bei den Umgebungsvariablen achten?
 
Werbung:
Eigentlich kann man das alles machen ohne Umgebungsvariablen zu setzen. Für den "normalen" Betrieb später ist es aber einfacher.

Code:
d:\temp\postgres>unzip -q postgresql-13.2-1-windows-x64-binaries.zip

d:\temp\postgres>dir
 Datenträger in Laufwerk D: ist data
 Volumeseriennummer: 98A6-075C

 Verzeichnis von d:\temp\postgres

24.02.2021  22:15    <DIR>          .
24.02.2021  22:15    <DIR>          ..
09.02.2021  07:27    <DIR>          pgsql
11.02.2021  09:57       214.345.722 postgresql-13.2-1-windows-x64-binaries.zip
               1 Datei(en),    214.345.722 Bytes
               3 Verzeichnis(se), 974.230.814.720 Bytes frei

d:\temp\postgres>.\pgsql\bin\initdb -D .\pgdata -W -U postgres -E UTF8 -A scram-sha-256

The files belonging to this database system will be owned by user "ARTHUR".
This user must also own the server process.

The database cluster will be initialized with locale "German_Germany.1252".
The default text search configuration will be set to "german".

Data page checksums are disabled.

Enter new superuser password:
Enter it again:

creating directory ./pgdata ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... windows
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... CET
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok

Success. You can now start the database server using:

    ./pgsql/bin/pg_ctl -D ^"^.^\pgdata^" -l logfile start

d:\temp\postgres>.\pgsql\bin\pg_ctl -w -D ".\pgdata" -l startup.log start
waiting for server to start.... done
server started

d:\temp\postgres>.\pgsql\bin\psql -U postgres -d postgres
Password for user postgres:
psql (13.2)
Type "help" for help.

postgres=# select version();
                          version
------------------------------------------------------------
 PostgreSQL 13.2, compiled by Visual C++ build 1914, 64-bit
(1 row)

postgres=#
 
Was genau ist daran schlimm?
Wenn jemand solche Leistungen unentgeltlich fordert kann ich es ja verstehen, dass es nicht gerne gesehen ist, aber ich möchte diese Leistung ja angemessen bezahlen.
Daran ist nichts schlimm. Es ist bei effektiv 2 Befehlszeilen einfach übertrieben.

befürchte aber, es nicht direkt zu schaffen und hier einige eher blöde Fragen stellen zu müssen.
Worauf muss ich denn bei den Umgebungsvariablen achten?

Wie ich schrieb, befindet sich auf meinem System bereits eine (mehrere) PG Installationen, die durch ggf. gesetzte (vorhandene) Umgebungsvariablen das Verhalten der Archivinstallation beeinflussen könnten. Es geht nur darum, diese Effekte auszuschließen. Hast Du keine Installer Version auf Deinem System (gehabt), gibt es dieses Problem nicht. Und ja, es ist kein Problem, Fragen zu stellen.
 
Ich habe initdb wie du gestartet und bekomme leider diesen Fehler:
Code:
E:\postgres\pgsql\pgsql>cd bin

E:\postgres\pgsql\pgsql\bin>initdb.exe -U postgres -W -E UTF8 -A scram-sha-256 E:\postgres\_pgdata
Die Dateien, die zu diesem Datenbanksystem gehören, werden dem Benutzer
»USER« gehören. Diesem Benutzer muss auch der Serverprozess gehören.

Der Datenbankcluster wird mit der Locale »German_Germany.1252« initialisiert werden.
Die Standardtextsuchekonfiguration wird auf »german« gesetzt.

Datenseitenprüfsummen sind ausgeschaltet.

Geben Sie das neue Superuser-Passwort ein:
Geben Sie es noch einmal ein:

erzeuge Verzeichnis E:/postgres/_pgdata ... ok
erzeuge Unterverzeichnisse ... ok
wähle Implementierung von dynamischem Shared Memory ... windows
wähle Vorgabewert für max_connections ... 100
wähle Vorgabewert für shared_buffers ... 128MB
wähle Vorgabewert für Zeitzone ... Europe/Brussels
erzeuge Konfigurationsdateien ... ok
führe Bootstrap-Skript aus ... 2021-02-24 22:27:33.218 CET [13336] LOG:  konnte Datei »pg_wal/xlogtemp.13336« nicht nach »pg_wal/000000010000000000000001« linken: Invalid argument
2021-02-24 22:27:33.230 CET [13336] FATAL:  konnte Datei »pg_wal/000000010000000000000001« nicht öffnen: No such file or directory
Kindprozess hat mit Code 1 beendet
initdb: entferne Datenverzeichnis »E:/postgres/_pgdata«

Ich habe es auf einem Rechner mit und einen ohne bereits bestehende PostgreSQL Installation probiert, jeweils mit dem gleichen Fehler.
Hat jemand eine Idee?
 
Vermutlich ein Berechtigungsproblem.
Existiert das in den Parametern angegebene Verzeichnis schon? Sieht nicht so aus. Ich hatte es bereits angelegt.
Aber ich bin auch mit einem Adminuser unterwegs gewesen. Hab nicht dran gedacht, das zu schreiben, weil ich während des Prozesses keine entsprechende Elevation Anfrage bekommen habe, spielt aber vielleicht doch eine Rolle.
Also für den Anfang:
- das Verzeichnis vorher anlegen
- als User mit Adminrechten arbeiten
oder
- cmd Shell "als Administrator" starten
Ist aber nur geraten.
Etwas exotischere Idee: Dein E: ist eben der benannte Stick und hat ein Dateisystem oder eine Ordnerberechtigungsstruktur, die das verbietet.
 
So und als nächstes mit vorher erzeugtem Data Verzeichnis: gleicher Fehler
Wenn man die Fehlermeldung genau betrachtet, ergibt sich auch ein Sinn. Es liegt am Dateisystem, FAT32 kann keine Links.
Also nächster Tipp:
Das Ganze lokal auf NTFS ausprobieren oder auf dem Stick, der mit einem Dateisystem formatiert ist, das Links kann.
Vielleicht gibt es auch Schalter, die die Handhabung von Dateilinks variieren, aber da hab ich jetzt keine Lust zu suchen.
 
Danke für den Tipp. Das scheint es gewesen zu sein. Hab es auf einem PC ohne bisherige postgres Installation gemacht, wie du in #29.
Das einzige was anders war ist der Select Befehl mit 'pg_settings'. Dort gab es die Fehlermeldung
Code:
FEHLER: Typ data_directory existiert nicht.

Eine Testtabelle konnte ich erstellen. Jetzt muss ich nochmal prüfen ob diese auch an einem anderen Pc vorhanden ist, sprich die Daten mit auf der externen Festplatte liegen.

Wofür sind eigentlich die "^" in manchen Befehlen? Scheint ja auch ohne zu funktionieren
 
Zuletzt bearbeitet:
Na das sieht nicht so gesund aus, das initdb schreibt ja, dass der user der owner sein muss.
Ich weiß aber auch nicht, ob die simple Abfrage des Wertes auch eine Prüfung nach sich zieht.

Die Zeichen dienen wahrscheinlich als Escape Code, damit auch bei schrägen Console Encodings in der cmd Shell der Befehl richtig ankommt.
 
Ich habe das Verzeichnis mal in den VeraCrypt Container kopiert und an verschieden PCs getestet. Läuft soweit. Die pg_settings Abfrage liefert jetzt auch ein Ergebnis wie bei dir - vllt war irgendwo ein Tippfehler. Vielen Dank auf jeden Fall für die Hilfe bis hier!!

Jetzt möchte ich gerne ein Backup einer Datenbank einspielen. Wie mache ich das am besten? Muss ich zuerst eine neue Datenbank mit dem Namen der DB aus dem Backup erstellen?
Beim Klick auf Restore in pgAdmin soll ich die BinaryPaths definieren. Wie sind die anzugeben? Einfach das bin Verzeichnis ?
 
Zuletzt bearbeitet:
Vermutlich, ich kenne pgadmin nicht, bzw. ich nutze es nicht.
Wenn Dein Backup per pgAdmin entstanden ist, sollte es wohl damit auch wieder restaurierbar sein.
Ich gehe mal davon aus, dass pgAdmin nichts anderes macht, als dort im Binary Verzeichnis ein tool zu suchen, z.B. pg_dump, ein Geschwister von initdb. Also kannst Du auch hier einfach mal nachschauen, wie man das in der Kommandozeile bedient. Auch hierzu gibt es Doku.
 
Werbung:
Zurück
Oben