While restoring backup customers may face issues similar to the ones mentioned below.

Restoring foreman dump [FAIL]
Failed executing runuser - postgres -c 'pg_restore -C -d postgres /transition/satellite-backup-2025-06-26-08-39-35/foreman.dump', exit status 1:
pg_restore: while PROCESSING TOC:
pg_restore: from TOC entry 4967; 1259 20295 INDEX index_fact_names_on_name_and_type foreman
pg_restore: error: could not execute query: ERROR: could not create unique index "index_fact_names_on_name_and_type"
DETAIL: Key (name, type)=(lscpu_flags, Katello::RhsmFactName) is duplicated.
Command was: CREATE UNIQUE INDEX index_fact_names_on_name_and_type ON public.fact_names USING btree (name, type);

pg_restore: from TOC entry 5507; 1259 3233544 INDEX index_katello_installed_packages_on_nvrea foreman
pg_restore: error: could not execute query: ERROR: could not create unique index "index_katello_installed_packages_on_nvrea"
DETAIL: Key (nvrea)=(gcc-objc++-4.8.5-44.el7.x86_64) is duplicated.
Command was: CREATE UNIQUE INDEX index_katello_installed_packages_on_nvrea ON public.katello_installed_packages USING btree (nvrea);

pg_restore: from TOC entry 5637; 1259 4054876 INDEX katello_available_module_streams_name_stream_context foreman
pg_restore: error: could not execute query: ERROR: could not create unique index "katello_available_module_streams_name_stream_context"
DETAIL: Key (name, stream, context)=(pmdk, 1_fileformat_v6, d63f516d) is duplicated.
Command was: CREATE UNIQUE INDEX katello_available_module_streams_name_stream_context ON public.katello_available_module_streams USING btree (name, stream, context);

Customers are facing this

• While doing a daily/weekly backup/restore
• Maintaining DR setups
• When leapp upgrade is not possible [upgrade using backup/restore]. This causes a huge amount of delay in fixing the duplicates and re-doing the backup before restoration.
  This issue renders the backup useless and cannot be restored on any system and the whole satellite server might be not recoverable at all.

The only way to detect this is to run db reindexing before backup.

This happens because of postgres dumps. Previously it was tar/untar . https://issues.redhat.com/browse/SAT-24936 is probably where we switched to dump method and this problem came into effect.

Possible fix ideas:

• We may add some fix in foreman-maintain or atleast make the backup fail citing these kind of issues.

Related KCS articles:
https://access.redhat.com/solutions/6998041
https://access.redhat.com/solutions/7053489
https://access.redhat.com/solutions/7004750