Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Satellite backup creates a *.tar.gz file with usual content like:
config_files.tar.gz
.config.snar
metadata.yml
mongo_data.tar.gz
.mongo.snar
pgsql_data.tar.gz
.postgres.snar
.pulp.snar
Since three far far biggest files are gzips already and the rest are small files only, the backup calls gzip on gzipped data. That is redundant and costs some time (to gzip and also gunzip during restore).
We should either create just satellite-backup-${timestamp}.tar, or optionally (and maybe better) keep the config_files + mongo_data + pgsql_data in tar format "only".
Version-Release number of selected component (if applicable):
Sat 6.11 or any older.
How reproducible:
100%
Steps to Reproduce:
1. Create a (full) foreman-maintain backup .
2. Check the tar.gz backup contains tar.gz files inside.
Actual results:
tar.gz contains tar.gz inside
Expected results:
Change either one tar.gz -> tar
Additional info:
I do understand the change must be backward compatible, i.e. new f-m must be able to unpack tar.gz-in-tar.gz (but nothing else wrt. backward compatibility..?). Which makes the request bit complicated. But still the overall gain in compressing and extracting files is worth of it, I think.
I have to take my request back, since no *one* tar.gz of whole backup is created:
Sat6.13 offline backup:
/backup/satellite-backup-2023-08-07-15-37-18:
config_files.tar.gz metadata.yml mongo_data.tar.gz pgsql_data.tar.gz pulp_data.tar
Sat6.13 online backup:
/backup/satellite-backup-2023-08-07-15-49-56:
candlepin.dump config_files.tar.gz foreman.dump metadata.yml mongo_dump pg_globals.dump pulpcore.dump pulp_data.tar
(similar content for e.g. 6.9 backups)
The satellite-backup.tar.gz had to be received from a customer as an extra manual activity, where the final gzip was the redundant one. So this is not a Satellite product issue.
Description of problem: Satellite backup creates a *.tar.gz file with usual content like: config_files.tar.gz .config.snar metadata.yml mongo_data.tar.gz .mongo.snar pgsql_data.tar.gz .postgres.snar .pulp.snar Since three far far biggest files are gzips already and the rest are small files only, the backup calls gzip on gzipped data. That is redundant and costs some time (to gzip and also gunzip during restore). We should either create just satellite-backup-${timestamp}.tar, or optionally (and maybe better) keep the config_files + mongo_data + pgsql_data in tar format "only". Version-Release number of selected component (if applicable): Sat 6.11 or any older. How reproducible: 100% Steps to Reproduce: 1. Create a (full) foreman-maintain backup . 2. Check the tar.gz backup contains tar.gz files inside. Actual results: tar.gz contains tar.gz inside Expected results: Change either one tar.gz -> tar Additional info: I do understand the change must be backward compatible, i.e. new f-m must be able to unpack tar.gz-in-tar.gz (but nothing else wrt. backward compatibility..?). Which makes the request bit complicated. But still the overall gain in compressing and extracting files is worth of it, I think.