Necesito hacerle una consulta, verifico o sabe aproximadamente cuanto pesaba esa tabla/base a respaldar? ya que debemos tener ese dato . Muchas veces cometemos el error de automatizar este procedimiento sin limpiar los espacios y como consecuencia .. el script comienza ( crea estructura), pero se cae a mitad de camino por no tener el espacio suficiente para ...
If you don't have the required permissions, pg_dump will give you an error message rather than an empty COPY statement. Moreover, permissions do not apply to superusers.
You should verify what the database user used by pg_dump sees when selecting from the original table.
The only explanations I can think of are:
Somebody deleted all rows from the table.
That is silly You should instead take one pg_basebackup per day and archive the transaction log with archive_command. That way. you can use point-in-time-recovery to restore the database to any given point in time.
See the documentation for more.
several hours seems a bit long for only 50gigs as other have stated. This tells us the IO on the server, or destination is bogged down or needs to be up-sized. Or this is network issue causing the slowness.
I suggest do a pg_dump and monitor the server resources, hard-drive, and Network and the destination to see where slowness is
Another option that ...
It depends a lot on details that you have not specified, particularly how the IO subsystem is arranged for this database instance. Single drive? Multiple? If multiple how is the data/uses spread over those drives? Drive types (spinning, SATA SSD, NVMe SSD, ..._)? Network rather than local and if net, what networking standards?
With 50Gb taking "several ...
Postgres pg_dump sacrificed memory allocation check to speed up the back up process. pg_dump should be rewritten to take into account out of memory problem. What I did was let pg_dump backup non-blob fields then I wrote a program to backup blob fields separately. I had to write a restore program too.