Re: Failed backup Job. How to find out why it failed.

Hi,

I am pretty sure, you can run the command I gave you on Windows, as I do it
too.
Can you run your command manually? Does it print anything to stdout/stderr?

On 6 March 2017 at 22:04, Rob Musitano <Rob(dot)Musitano(at)ldc(dot)com> wrote:

> Daniel.
>
>
>
> Thanks for responding. I think I left out a key piece of info. I have
> this on a Windows server and I believe that the additional cmds are for
> Unix.
>
>
>
> From my findings I see the information below but a restart is in order. I
> was hoping to see this on a per cmd basis. Is there another way on a
> Windows based server to output err logs per run?
>
>
>
> Thanks
>
>
>
> Rob
>
>
>
> #-----------------------------------------------------------
> -------------------
>
> # ERROR REPORTING AND LOGGING
>
> #-----------------------------------------------------------
> -------------------
>
>
>
> # - Where to Log -
>
>
>
> #log_destination = 'stderr' # Valid values are combinations of
>
> # stderr, csvlog, syslog and
> eventlog,
>
> # depending on platform. csvlog
>
> # requires logging_collector to
> be on.
>
>
>
> # This is used when logging to stderr:
>
> #logging_collector = off # Enable capturing of stderr and
> csvlog
>
> # into log files. Required to be
> on for
>
> # csvlogs.
>
> # (change requires restart)
>
>
>
> # These are only used if logging_collector is on:
>
> #log_directory = 'pg_log' # directory where log files are
> written,
>
> # can be absolute or relative to
> PGDATA
>
> #log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # log file name
> pattern,
>
> # can include strftime() escapes
>
> #log_truncate_on_rotation = off # If on, an existing log file of
> the
>
> # same name as the new log file
> will be
>
> # truncated rather than appended
> to.
>
> # But such truncation only occurs
> on
>
> # time-driven rotation, not on
> restarts
>
> # or size-driven rotation.
> Default is
>
> # off, meaning append to existing
> files
>
> # in all cases.
>
> log_rotation_age = 7d # Automatic rotation of logfiles
> will
>
> # happen after that time. 0
> disables.
>
> #log_rotation_size = 10MB # Automatic rotation of logfiles
> will
>
> # happen after that much log
> output.
>
> # 0 disables.
>
>
>
>
>
>
>
>
>
> *From:* Dániel Asztalos [mailto:daniel(dot)asztalos(at)puppetworks(dot)eu]
> *Sent:* Friday, March 03, 2017 4:34 AM
> *To:* Rob Musitano <Rob(dot)Musitano(at)LDC(dot)com>
> *Cc:* pgadmin-support(at)postgresql(dot)org
> *Subject:* Re: [pgadmin-support] Failed backup Job. How to find out why
> it failed.
>
>
>
> Hi,
>
>
>
> you should redirect the output of the pg_dump command to a file to see the
> error. Do something like:
>
> %PGBIN%pg_dump -i -h %PGHOST% -U %PGUSER% -F c -b -v -f
> "%BACKUPDIR%serverpub-%year%%month%%day%%hh%%nn%.compressed" serverpub* 1>
> %LOG_FILE% 2>&1*
>
>
>
> On 2 March 2017 at 23:04, Rob Musitano <Rob(dot)Musitano(at)ldc(dot)com> wrote:
>
> All.
>
>
>
> I have a backup job that runs each day yet it shows failed. How can I see
> why it failed or where the error is? I searched across PGADMIN and cannot
> locate a log that shows me the details. The only location that I see
> failed status is at the job in Properties and in the Statistic listing.
> Where can I see more of the output or errors that lead to this status.
>
>
>
> The job is listed as Routine Maintenance and to get to Success I have ‘On
> Error’ temporarily set to ignore.
>
>
>
> I’m using pgAdmin 1.14.3
>
> PostgreSQL : 9.1.14-1
>
>
>
> Example of my run:
>
> %PGBIN%pg_dump -i -h %PGHOST% -U %PGUSER% -F c -b -v -f
> "%BACKUPDIR%serverpub-%year%%month%%day%%hh%%nn%.compressed" serverpub
>
>
>
> Thanks in advance.
>
>
>
> Rob
>
>
>
>
>
>
> ------------------------------
>
>
> *CONFIDENTIAL This message and any attachments (the "Message") are
> confidential and intended solely for the addressee(s). If you are not the
> intended recipient, any use, copying or dissemination is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return and delete this original Message and any copies from
> your system. E-mails are susceptible to alteration. Louis Dreyfus Company
> BV and its subsidiaries and other affiliates shall not be liable if the
> Message is altered, changed or falsified. *
>
> *This is an environment friendly email. Please do not print it unless it
> is really necessary.*
>
>
>
>
>
> --
> ------------------------------
>
> *Dániel Asztalos* developer
> PUPPETWORKS STUDIOS
>
> E-mail: daniel(dot)asztalos(at)puppetworks(dot)eu
> Skype: dani.asztalos
> Mobile: +36 30 875 0727 <+36%2030%20875%200727>
> Phone: +36 1 240 3537 <+36%201%20240%203537>
> Web: www.puppetworks.eu
>
> ------------------------------
>
>
> ------------------------------
>
>
> * CONFIDENTIAL This message and any attachments (the "Message") are
> confidential and intended solely for the addressee(s). If you are not the
> intended recipient, any use, copying or dissemination is strictly
> prohibited. If you are not the intended recipient, please notify the sender
> immediately by return and delete this original Message and any copies from
> your system. E-mails are susceptible to alteration. Louis Dreyfus Company
> BV and its subsidiaries and other affiliates shall not be liable if the
> Message is altered, changed or falsified. This is an environment friendly
> email. Please do not print it unless it is really necessary. *
>

--
------------------------------

Dániel Asztalos developer
PUPPETWORKS STUDIOS

E-mail: daniel(dot)asztalos(at)puppetworks(dot)eu
Skype: dani.asztalos
Mobile: +36 30 875 0727
Phone: +36 1 240 3537
Web: www.puppetworks.eu
------------------------------