Author Topic: SMF admin panel backup is crap! Can we have a patch release to remove it please? (Read 34398 times)

IchBin™ · « **Reply #40 on:** April 24, 2012, 06:17:54 PM »

If they don't have restrictions, then they are allowed to upload a script like big dump? They're allowed to use better tools than what we can provide?

Antechinus · « **Reply #41 on:** April 24, 2012, 06:43:40 PM »

I'm in two minds about this. Yes, our current backup script does have limitations. However, it used to do perfect backups until my site reached 20 meg zipped, at which point I changed to using a cron job for backups.

I did find the built-in script very valuable in the early stages of running the site as a complete n00b who knew absolutely nothing. I realise it is not as reliable on all servers, and that getting perfect 20 meg zips from it is unusual.

The reasons why it did so well on our box must be partly due to server config, and I'm happy to provide details of that if they are useful. The other thing is that I ran up against the default limit for script execution time very early on, which was truncating the backups to bugger all. I noticed that straight away when I got a backup that was smaller than the previous one. Searching here quickly provided me with a way to up the limit to something more useful.

Really, anyone who is interested in backing up their site should be keeping an eye out for anomalies like that. It's just basic common sense IMO. If people are not prepared to keep an eye out for bloody obvious malfunctions, then there's probably not a lot we can do for them.

I'd be in favour of adding information about the scripts limitations asap, and then looking at whether it can be improved.

butchs · « **Reply #42 on:** April 24, 2012, 08:18:14 PM »

I used to back up from both php and SMF. Now I will just use php.

ziycon · « **Reply #43 on:** April 25, 2012, 04:07:26 AM »

Personally I think that there should be a way to take backups from within SM but for obvious reason you wont be able to restore a backup through the interface. It helps with people that aren't as technical and makes it easier for they to have piece of mind instead of having to rely on someone else or their host to make sure they have a recent backup in a worst case situation.

emanuele · « **Reply #44 on:** April 25, 2012, 12:23:54 PM »

So, I just finished a dump (plain text for the moment) of a 2.8 GB database with the internal SMF backup utility (MySQL only at the moment), it's a bit slow (20 minutes...that is not so good for consistency, but is still probably better than nothing).

The question is: should I debug it, test it with PostgreSQL, with compressed output, try to find few other optimizations and commit it or commit the complete drop of the tool?
Let me know.

Sir Osis of Liver · « **Reply #45 on:** April 25, 2012, 01:39:35 PM »

It should work for all users, at all experience levels, across all server platforms. If it can't be fixed to do that, it should be removed, because the result can be disastrous for the users most likely to rely on it, and least likely to understand what's happening.

Kindred · « **Reply #46 on:** April 25, 2012, 02:38:58 PM »

Well, I disagree.

I think that a little debugging and optimizations would go a long way rather than dropping the tool (which has never failed for me, mind you - I can't recreate the problem on 3 different servers/sites. LOL!)

Adish - (F.L.A.M.E.R) · « **Reply #47 on:** April 25, 2012, 02:40:35 PM »

Oh! And it is also dependently on browser execution time too. Some browsers give up after a few minutes of wait time. So, that is another problem that needs tackling if we going to get all perfect

Kindred · « **Reply #48 on:** April 25, 2012, 02:41:41 PM »

well, I don't know about that --- since even the phpmyadmin backup fails for me on my 3.7 gb database over a browser.

kat · « **Reply #49 on:** April 25, 2012, 04:16:12 PM »

So, maybe a note saying "Don't trust this method of backing-up your database, coz it's bollox. Use your CPanel, or equivalent, if you can." would be best, to keep F.L.A.M.E.R. and Kindred happy, then?

vbgamer45 · « **Reply #50 on:** April 25, 2012, 04:19:04 PM »

Quote from: Kindred on April 25, 2012, 02:38:58 PM

Well, I disagree.

I think that a little debugging and optimizations would go a long way rather than dropping the tool (which has never failed for me, mind you - I can't recreate the problem on 3 different servers/sites. LOL!)

Maybe have some kind of progress bar and do it in chunks instead of all at once. Like the upgrade tool. And just have the chunks written to disk.

emanuele · « **Reply #51 on:** April 25, 2012, 04:34:24 PM »

Quote from: Krash. on April 25, 2012, 01:39:35 PM

It should work for all users, at all experience levels, across all server platforms.

Something so comprehensive is totally impossible.

What I can say is: I wrote down this code, is not so different from the previous, it "simply" split the backup in chunks (well not exactly, not only, but that's not the point here).
The limits are more or less (I still have to optimize it a bit) the limits that phpMyAdmin has: almost none with plain text dumps, few with zipped dumps because of the way phpMyAdmin handles the backup I discovered they are almost useless if bigger then a certain size, pmyadmin concatenates gzencode/bzcompress outputs, but these cannot be concatenated, resulting in a file that has only the first echo readable, at least here on my box).

Additionally it takes time. That's not something related to server overheating or the fact you should stay in front of the computer waiting for the backup to finish, but is something related to data consistency. Think about it: if the backup takes 20 minutes it means that if something happens during these 20 minutes (a post, a new topic, a ban, whatever) this could be lost. Or, since the backup scans the entire database from the first table to the last, it could create inconsistent data: if new member registers while the backup is at {db_prefix}messages and this new user posts a message, in the backup the message could appear, but the corresponding user will not (because {db_prefix}members is before {db_prefix}messages).
So for "big databases" the maintenance mode would be mandatory in order to be sure the backup is "good enough".

There are few things to take in consideration.

Quote from: Kindred on April 25, 2012, 02:38:58 PM

(which has never failed for me, mind you - I can't recreate the problem on 3 different servers/sites. LOL!)

Just because you don't use it?

Kindred · « **Reply #52 on:** April 25, 2012, 04:47:16 PM »

lol, silly... I have used it, previously on my smaller forums.

When I need to do a quick backup without going through the trouble of logging into the site's control panel

kat · « **Reply #53 on:** April 25, 2012, 05:03:40 PM »

Quote from: vbgamer45 on April 25, 2012, 04:19:04 PM

Maybe have some kind of progress bar and do it in chunks instead of all at once. Like the upgrade tool. And just have the chunks written to disk.

The problem with doing it in chunks on the server, is that for the entire time those backups are being written, they have to be written somewhere that is server-writable (i.e. 777) and thus can be readily tampered with.

Adish - (F.L.A.M.E.R) · « **Reply #54 on:** April 25, 2012, 05:12:22 PM »

PhpMyAdmin does give out incomplete backup's too by the way no matter if it is plain text .sql or compressed in .zip .tar or .tar.gz. The settings are dependent on my.cnf config by the host. Many times, they have a mysql dump setting which stops the backup once a certain size is reached.

Antechinus · « **Reply #55 on:** April 25, 2012, 07:34:02 PM »

Quote from: Krash. on April 25, 2012, 01:39:35 PM

It should work for all users, at all experience levels, across all server platforms. If it can't be fixed to do that, it should be removed, because the result can be disastrous for the users most likely to rely on it, and least likely to understand what's happening.

Analogy: if a certain medicine is not effective in all cases, it should be removed from distribution.

Sir Osis of Liver · « **Reply #56 on:** April 25, 2012, 08:28:43 PM »

No, but if a medication is found to be harmful to a majority of users, it should, and sometimes is ($$$$ notwithstanding) taken off the market. It's not a question of the backup feature being useful to a minority of users, and harmless to others. It can, and does, trash forums.

青山素子 · « **Reply #57 on:** April 25, 2012, 08:41:59 PM »

Quote from: Krash. on April 25, 2012, 08:28:43 PM

No, but if a medication is found to be harmful to a majority of users, it should, and sometimes is ($$$$ notwithstanding) taken off the market. It's not a question of the backup feature being useful to a minority of users, and harmless to others. It can, and does, trash forums.

If you wanted your analogy to be correct, the backup feature would have to break existing boards. I haven't seen any reports of such. Rather, the tool lacks efficacy in providing working backups under some conditions. That's more a matter of "this drug doesn't work in 20% of cases" than "this drug is causing strokes".

Sir Osis of Liver · « **Reply #58 on:** April 25, 2012, 08:46:33 PM »

This thread was spun off (by K@) from yet another thread about a board that was trashed and had an unuseable backup from the admin feature.

Antechinus · « **Reply #59 on:** April 25, 2012, 08:51:16 PM »

Ok, I'm interested. Why was the backup unusable? Was it truncated, or was there some other problem?

News:

Author Topic: SMF admin panel backup is crap! Can we have a patch release to remove it please? (Read 34398 times)

kat

kat