Wygląda na to, że próbujesz zweryfikować poprawność i poprawność właśnie utworzonego zrzutu PostgreSQL.
Twoim kluczowym nieporozumieniem jest to, że nie musisz przywracać zrzutu do tej samej bazy danych, z której go utworzyłeś . Możesz przywrócić do innej bazy danych w tym samym klastrze lub, dla dodatkowej paranoi, bazę danych na innym klastrze (serwerze). Sprawdź, czy zrzut został przywrócony bez błędów i czy dane są zgodne z oczekiwaniami.
Aby uzyskać dodatkową paranoję, zatrzymaj serwer PostgreSQL i skopiuj pliki z katalogu danych. W ten sposób masz również kopię zapasową na poziomie plików. Pamiętaj, że kopie katalogów danych PostgreSQL na poziomie plików mogą tylko być odczytywany przez tę samą główną (8.1/8.2/...) wersję PostgreSQL zbudowaną z tą samą opcją na tej samej platformie - więc jeśli katalog danych pochodzi z 9.2.x na Windows x64, może być odczytany tylko przez inny Windows Host x64 z zainstalowanym 9.2.x.
Jeśli martwisz się o swoją oryginalną bazę danych, prawdopodobnie nie masz kopii zapasowych. To jest krytyczne problem. Musisz pilnie przeczytać rozdział dokumentacji na temat tworzenia kopii zapasowych i przywracania i uzyskaj dobry zautomatyzowany schemat tworzenia kopii zapasowych. Spójrz na barman .
Aktualizacja po edycji pytania :
-F t to dziwny wybór; zwykłe zrzuty SQL lub -F c zwykle ma więcej sensu.
Utworzony plik nie jest plikiem .gz (skompresowany gzip), w każdym razie jest to plik .tar archiwum, nieskompresowane. Można go rozpakować do katalogu pełnego plików SQL.
Aby to przetestować, użyj pg_restore aby przywrócić go do nowej pustej bazy danych utworzonej za pomocą createdb lub CREATE DATABASE polecenie.
