Checkpoints and Resume

Archiving a large table can take hours. GoArchive records its progress as it goes, so an interruption costs you the current batch rather than the whole run.

What gets recorded #

GoArchive maintains its own tracking tables on the destination server:

• A job record holding the position reached — the furthest point in the root table that has been fully processed.
• A per-job log holding one entry per root row, with its state: discovered, copied, or completed.

Together these describe exactly how far a run got and what state each row was left in.

Resuming #

To resume, run the same command again:

goarchive archive -c archiver.yaml --job archive_old_orders

There is no separate resume command and no flag to remember. GoArchive reads its own records, works out what remains, and continues.

What resuming actually does #

Resume is aware of the state each row was left in, so no work is repeated unnecessarily:

A row whose data was already copied and verified is not copied again. Only the step that did not finish is carried out.

Progress is recorded atomically #

The position is advanced in the same operation that marks rows completed. There is no state in which the recorded position claims progress that was not actually finished. That is what makes resuming reliable rather than approximate.

Stopping cleanly #

Interrupting with Ctrl-C, or sending the process a termination signal, asks GoArchive to stop at the next batch boundary. The batch in progress finishes, its results are recorded, and the process exits.

^C
Graceful stop requested — finishing current batch

Running the command again continues from that point.

One job at a time #

While a job runs, GoArchive holds a lock and refreshes a heartbeat, so a second run of the same job cannot start alongside the first. The same protection applies to two different jobs that share a root table.

If a previous run ended without releasing its lock, GoArchive reports the situation and tells you how to clear it, rather than proceeding and risking two processes working on the same rows.

Inspecting progress #

Progress is visible in the tracking tables while a job runs:

SELECT id, job_name, job_status, last_processed_root_pk_id
FROM archiver_job
WHERE job_name = 'archive_old_orders';

The tracking tables live in the destination database by default, or in a schema of their own if you configure one. See Database Connections .