Could be handy to have I guess. Neat little feature.
Had backup zip generated nicely.

Naming of zip and sql would be more practical to be site related rather than generic.
For the quick test I had greyed out in sql from middle of content table insert.

Not sure why this is needed in core when there are perfectly good free options like akeeba backup

Nice Idea to have a Database Backup Function in Joomla Core!

@photodude IMO this script should not stay in concurrence with backup extensions. Perhaps the naming is misleading. It would be nice to have a lightwight dump functionality. Like that it will be much easier for extension devs to reproduce issue from clients on their dev server.

What would be nice to have the possibility to select certain tables only. But can be done in a second step.

can we use the https://github.com/joomla/joomla-cms/blob/staging/libraries/joomla/database/exporter.php instead with #14272

It would be great to have such a easy way for quick database backups!

How are you going to import?

How are you going to import?

Probably using phpMySQL or any other tool which allows to apply SQL files.
I'm not sure if we need a way to restore the backup/dump from within Joomla. It's probably better to do it from an extern tool anyway since you're going to overwrite the session and user tables.

Just tested this and the file generated was backup.zip with a file inside it called backup-2017-05-05-21-42-39.sql which doesnt look correct

I'm not sure if we need a way to restore the backup/dump from within Joomla

The problem is this works for mysql. But on phpPgAdmin (the postgres equivalent of PhpMyAdmin) the import feature requires a different XML input - but we use the same (mysql) export standard across the entire of Joomla's export features (for consistency - but in this case this hurts us)

Thank you for all your input.

Now I think, we can (if the script is still desired) start optimizing.... PR are welcome :)

In phpMyAdmin, under File to Import, this is stated. The import works with the filename format in this PR. However, you may want to change it to match as stated here.

File may be compressed (gzip, bzip2, zip) or uncompressed.
A compressed file's name must end in .[format].[compression]. Example: .sql.zip

I would like to see this feature in the core. As I discussed with @bembelimen at Glip, the bottleneck are the environment limits on many servers which will lead to time-outs and broken files if the database is really big.

Next step would be to create a Ajax-based approach to bypass these limits. Another thing to solve is how to handle the archiving process of big dumps. A possible solution would be to determine the limits and offer the plain dump as download with a message that the file couldn't be compressed due to insufficient resources.

• Create database dump via small, successive Ajax-requests
• Solve archiving issue of huge file sizes
• Add option to exclude (clean) tables, e.g. session (optional)

Cheers

I'm still working on this script (as the first try was a test, if this is possible).

I created a branch where I will commit the development status and where I will merge into this PR, when we have a stable version: https://github.com/bembelimen/joomla-cms/tree/database-backup-test

So the good news are:

• we can now (probably) dump all sizes of databases (they will be stored in the tmp folder atm)

The bad news are:

• to archive this, I had to rebuild the creation process, which means, that I have to implement a new zipping and download method. This will be the next steps

• We also need a good error handling.

Future features:

• Improve the options, so a user can define which tables he/she/it wants to export. ( @Kubik-Rubik ?)

So help is very welcome, just check out the test branch from above and send me a PR :)

I have tested this item ✅ successfully on 270fdfb

So, a first stable version is here now, tests are welcome!

I have tested this item ✅ successfully on 270fdfb

I've tested successfully in 3.7.5. The export is complete, the export file has about 22MB.

I have configured my browser to store downloads at once, so it took me some time findig the file in my download folder. I'd like to have some sort of feedback with name of the file or maybe the possibility to choos a own name for the export file.
Would be useful for a series of tests.

RTC after two successful tests.

Before I am comfortable even considering merging this (and to be honest since the day I saw this PR opened it felt like core was starting to go into competition with backup extensions), this MUST be tested to scale against large data sets. The "2 tests, RTC, merge" process can not fly here.

It also needs to be tested with all supported databases and remote databases

Hi @mbabker

it felt like core was starting to go into competition with backup extensions

No, I don't think so, I see a big difference between a quick dump and e.g. Akeeba

this MUST be tested to scale against large data sets. The "2 tests, RTC, merge" process can not fly here.

Agree

I have removed RTC for the reasons stated above

Yes, I get it is much different and much less scaled down than a proper backup solution, but adding it to core will result in competing with backup extensions because core will then offer at least the functionality to backup your database. It might just be me being overly analytical or trying to cover my own backside, but it does have a chance of causing some chatter and issues. (FWIW I don't think it's necessarily a bad idea, but it definitely needs to be "right")

I agree that more tests are needed.
But I do not see that this is in concurrence with big backup tools. In fact I'd like to have another name for the feature, "database export" would come closer to the intention.
Of course I can use the export as a database backup.
For me it is a nice feature to export the database before I test something, not for replacing big backup tools.

While testing this on a 800mb dump file, I got an 500 error.

I have 4 additions to the download code:

1. Sent the headers before sending the file
2. Add set_time_limit(0) before sending the file
3. Stop output buffering before sending the file with ob_end_clean()
4. Add flush() into the while loop

database.raw.php could look like this

JFactory::getApplication()->setHeader('Pragma', 'public')
 ->setHeader('Content-Type', 'application/sql')
 ->setHeader('Content-Disposition', 'attachment; filename=' . JApplicationHelper::stringURLSafe($host) . '.sql')
 ->setHeader('Content-Length', filesize($dump))
 ->sendHeaders();

ob_end_clean();

$sizelimit = 1024 * 1024;

while (!eof($handle))
{
 echo fread($handle, $sizelimit);
 flush();
}

I also tried to add realtime compression on output to get a sql.gz file but I think that will not be possible.

After adding this changes, it work perfectly.

Thanks @HLeithner

it dump all database tables maybe is better to dump only the joomla #__table 's
but ?

@alikon good point - if someone has installed multiple joomla sites or even something else on the same database then the backup should not include it

@alikon I implemented your idea, could you look into it? Thank you for your suggestion!

tested on latest staging with 15k articles

with:

• memory_limit=128M got PHP Fatal error: Allowed memory size of....
• memory_limit=512M got the 168MB backup file ?

some things

• we should prevent the poor settings in some way
• we should consider to zip the backup in some way

imho this feature can't compete with pro/com solutions cause of lack of restore, but surely we can all agree that if it should be a core feature must be "right"

p.s.
it dumps only site tables prefix now ?

If you don't mind me asking, what good would this feature bring for the day to day management of a Joomla website by a non-developer user (like me)?, considering that a backup needs all the website files as well?

Sounds neat, but I don't see this as an improvement over the default DB optimization feature that already packs with Joomla.

having the chance to save your data is a feature, developer or not

@alikon

I understand that, my question is; does it add to Joomla in a way users will acknowledge as useful or just bloat Joomla core?

I mean no offence here, I know you all dedicating your time here.

I do agree with @Ooops-404 here :/

I do agree as well with @Ooops-404 There are sufficient backup solutions available.

To be honest this looks like it has been abandoned by @bembelimen as he hasn't responded to the issues raised by @alikon

Yeah, the features are there. The idea was not to implement a whole backup script (There is Akeeba for this) but just a quick dump.

Ofc PR for this PR are welcome, but for a basic implementation (if this ever happens) I think it's "feature complete"

You might consider it to be feature complete but as it doesn't work then it can't be merged

personally speaking it's more like a "political" decision than a "feature complete"
i will be very happy to submit/help with pr to this one if only we can have some kind of decision
but i'm afraid that here is more about "politics" than other things
?

@alikon maybe I'm a bit naive but what is the political problem? I would love to see this feature in core.

this PR needs a Decision by Maintainers.

@HLeithner me too want to see this feature in core

what is the political problem?

Should be that someone will see this like a competing with backup extensions (is not for imho)

I can't understand how someone could think that this is anything near a backup solution...

It simply dumps some database tables, like mysqldump or phpmyadmin nothing more nothing less.

It would be the same if someone think that ftp is a backup solution.

I don't think this is helpful to the main Joomla Interface and I haven't really been convinced by the arguments here. So I'm going to reject this as a feature

please,
can you elaborate a bit more ?

Sure. The majority of our users are going to consider this a backup feature and will not understand the limitations. Either we're going to end up having a full blown backup feature in core (this is just not needed) or we're going to get bombarded with support tickets.

thanks for the answer