Resolved where is the nginx & apache settings in the backup?

[larryk]

Hi,
I downloaded the whole backup and can't find where the settings/config are at?

I have incremental turned on in Onyx :
OS ‪CentOS Linux 7.2.1511 (Core)‬
Product Plesk Onyx
Version 17.0.17 Update #20, last updated on Mar 23, 2017 03:12 AM


I downloaded the tar: backup_info_1703070323_1703110323.xml (like 12g)
I untared it and see LOTS of other files/targs, etc.

where do I go to see what the setting/config were?

NOTE: just restoring from a backup is NOT what I need to do.
I just want to SEE something from an old / prior config

thanks!

PS. looking specifically for, WHAT the information/settings/directives were on this page:
Apache & nginx Settings

 

[Bitpalast]

I think that the configuration files are not stored, but the psa database is dumped and stored as a database dump file. Web server configuration files are generated from the entries in the psa database if needed. You will need to look for the psa database dump file. I never needed that before, so I cannot exactly tell you the filename, but I am sure that there must be a dump in the backup archive.

 

[larryk]

thanks Peter,

I looked a dump file... 9 mg (it was not readable via textwrangler file viewer/editor)... well, very little was readable .

so yes, i really hope someone knows how to SEE this info!!!

a thought... i wonder if I can restore the backup to ANOTHER test site?
anyone done that before?

 

[Bitpalast]

You found the .sql dump file? Great. Then you can import it into any (empty) database and see the domains and other settings.

 

[larryk]

well, no...

saw:
dump-header (only 2kb)
dump-index (the one i can't read, but its 9 megs)
under databases/ ( there are tgz files, but those are the database i have on the domain)

dont' see any other dump or database files?

but every thing else is tgz files?

 

[DenisG]

Majority of settings is stored in files like backup_info_XXXXXXXXXX.xml. 'Apache & nginx Settings' are stored in the section 'web-settings' of these files.

 

[Bitpalast]

Thank you. Good to know. I just extracted a backup to understand that structure better. No .sql files (many of them, but at least none for the domain data), but all data in the .xml file.

Why not export it as a psa dump as Plesk is doing it upon database repair? That would be much easier to manually restore in case of emergencies. Maybe in a future version?

 

[DenisG]

Thank you. Good to know. I just extracted a backup to understand that structure better. No .sql files (many of them, but at least none for the domain data), but all data in the .xml file.

Why not export it as a psa dump as Plesk is doing it upon database repair? That would be much easier to manually restore in case of emergencies. Maybe in a future version?

This is a complex question. There are advantages and disadvantages for each solution... But anyway it is difficult to change the current behavior.

 

[trialotto]

@Peter Debik (and @DenisG)

Your question(s)

Why not export it as a psa dump as Plesk is doing it upon database repair? That would be much easier to manually restore in case of emergencies. Maybe in a future version?

are valid to a great extent.

The current backup protocol is simple: "gather files and data to be backed up, make tar archive and compress the archive".

Nevertheless, there are many pitfalls to that "protocol" and your questions are only dealing with one particular aspect of the backup process: mysql dumps (i.e. backups).

In particular, I am personally interested in "dynamic backups", consisting of a set of files with the possibility of having multiple versions per file and the possibility to backup and restore particular versions of those files (note that this is very different from the current incremental backup option).

I can also ask: "maybe in a future version?"

The truth is that @DenisG has made a point, even though it is not about difficulty.

In fact, I can assure you that the current backup protocol is the most efficient in terms of processes and storage space, even though the backup process as a whole is rather suboptimal and somewhat counter-intuitive.

Nevertheless, I am still researching a backup process that combines all the advantages of incremental and regular backups, including mysql dumps.

It is doable, but tricky in terms of storage space.

I will keep you posted, if you would like me to.

And if you have some special feedback or wishes with respect to backup processes, just let me know via a PM.

Regards.........