suggestn:sql backup

[Cool Surfer]

sql backup on server or remote server, from with acp would be a good addition to v3.

:blink: :blink: :blink: :blink: :blink: :blink:

[bfarber]

And would be EXTREMELY unreliable. ;) I'm not so sure I'd want to support the feature. It could easily timeout with any database larger than a few megs.

[FrostedPopTart]

What about implementing a setup like Bigdump has? Like you could "stagger" it so that the importer imports, say; 5000 lines of data, "pauses" to let the server breathe for a few seconds, then imports another 5000 lines, etc., so on and so forth until the database is 100% imported.

[Watty]

What about implementing a setup like Bigdump has? Like you could "stagger" it so that the importer imports, say; 5000 lines of data, "pauses" to let the server breathe for a few seconds, then imports another 5000 lines, etc., so on and so forth until the database is 100% [b]imported[/b].

exported. :P

[bfarber]

But, this is a forum software. IPB is not meant to be a database management utility - there are scripts that are designed to handle databases (large and small) already, so why should we invest the hours it would take (and by hours I mean, a LOT) to built database management utilities into IPB like you are talking about?

Wouldn't our time be better invested improving posting routines, bbcode parsing, member management faculties - you know, forum related things?

[Lindsey_]

Yes please spend time on FORUM and IPB 3.0 ;)

[stoo2000]

Yes please spend time on [b]FORUM[/b] and[b] IPB [/b]3.0 ;)

Blimey calm down, they have already stated they are planning it, Are you not happy with 2.3.x ? I find it very stable, and I'm happy with it until and more new versions come out. With our new site->forum integration any major changes will break our site so I'm not fussed when an update would come, as it would mean more work for me :lol:

[Labonte18]

Importing.. I don't technically agree with.. You'd have to be in the ACP to import the data.. Then do you drop tables? Or do you just export the data? If that's the case, what if you did just the data backup, and had to restore the entire DB, and don't have the tables? Then you're screwed.

I think to RELIABLY import the data, you would need to do JUST a data export, and then have a data backup and a full backup, which would then be confusing.

Right now, honestly.. Work needs to be done on the existing BACKUP functionality to make it as reliable as possible. And, I think something that creates the backup on the server and then gives you the option to download might be the way to go.

Just saying.. Hey.. Let's get what's there already working good before trying something else. Not knocking Brandon on this.. Just that it's the same basic backup script from 1.2.. And people who have a DB that's big-ish.. It just doesn't work well for.

[bfarber]

Personally, I'd say rip it out. But I don't think that would go over well.

Unfortunately it's rather hard to make it reliable, because so many servers have so many different settings. Generally it works fine as long as you don't gzip the backup, and your max_execution_time is long enough that it won't time out (we run set_timelimit for the ACP setting timeout to 0, which works in most cases, so timeout isn't an issue).

[Louis M.]

+1 to rip it out Brandon.

Servers have backup programs for this reason.

[Lindsey_]

+1 Rip it out also

Every hosting company have backup tools these days

[AndyF]

+1 for removal of it.

Imo, it may lead people into a false sense of security thinking they have a backup (when it may not be complete)