Thread

I have tried both plain text and Gzip. When I try Gzip, Safari just immediately starts decompressing index.php.gz, and never completes the process. When I do plain text, Safari downloads a file called ‘index.php’ which is 0 kb in size.

Does it sound like I have a setting that’s off?

It may be an issue with your database being large enough that the memory you have available isn’t enough to handle a backup from within EE. That was the case for me. However, I don’t believe I ended up with 0 kb files when trying plain text backups, so it is possible that it is something else. But if it used to work and now has stopped to work, then it could be a case of your database having grown too large to handle this way.

have you tried it with firefox, or some other browser? the last version of safari did that to me, but the beta version (or firefox) did the trick.

I tried in Firefox 2.0.0.1 and Safari 3.0 beta. Both give me the tiny file.

FWIW, my database is about 280 MB. No idea if that is huge or not as far as databases go 😉

wow. mine’s only 12.3 MB…

maybe you could go the long route and back up each table individually:

cp>admin>utilities>manage database tables

hope you get this solved! backing up is soooo important, as i have learned the hard way… heh

Daniel and Linda are both on the right track. You could perhaps reduce the size of your existing database by removing referrers, reduce the number of saves your templates default to, and potentially trim down either your members list based on some sort of criteria, or some of your content.

You also might very well have to do an incremental backup if you’re running out of PHP memory.

Or try PHPMyAdmin or something similar to back up.

I have two sites where the db backup won’t work. On one, the huge table is exp_revision_tracker (63.7 MB) and the other is exp_relationships (269.3 MB). On the first one I no longer need the revisions. Can I just remove every row from the table from phpmyadmin safely? The other one, with exp_relationships, I obviously need. How else to do the backup, if it’s too big and timing out?

Adam, what I did was turn off revisions globally, then made a backup copy of my exp_templates table, and emptied the exp_revision_tracker via Eskuel (a PHPMyAdmin clone).

Then I turned revisions back on again, but set the number to a slightly lower number, made a change and verified that my changes were saved. (They were.)

You’re probably going to need to download your database manually using PHPMyAdmin. One trick you could use is to download the exp_relationships table by itself, then temporarily rename the exp_relationships table to something like big_relationships, then try to download the backup.

EE won’t “see” the big_relationships table, and so you’d be able to get everything else down.

Just don’t forget to rename it back again.

Make sense?

I tried all of this myself before recommending you use it. Just make sure you turn the site off while doing this. (And turn it back on again when finished.)

Thanks for the reply, Sue. But isn’t the exp_relationships table necessary? Or does it get bloated with unnecessary data and can be reduced? I’m not sure how it works. I mean, if I remove that table and let the system rebuild it, am I not breaking my site’s content?

Renaming the exp_relationships table is temporary, just long enough to allow you to download a backup. Previous to a full backup, you would have already downloaded the real version of exp_relationships.

One trick you could use is to download the exp_relationships table by itself, then temporarily rename the exp_relationships table to something like big_relationships, then try to download the backup.

EE won’t “see” the big_relationships table, and so you’d be able to get everything else down.

Just don’t forget to rename it back again.

If your database is over 20-40MB, I personally see no reason to be trying to get reliable backups via any web-based tool, whether it’s ExpressionEngine, phpMyAdmin, or otherwise.  This is your data, afterall: the spine of the site’s livelihood.  If the host does not make available regularly scheduled, frequent backups, perhaps ask them to do it via the command line for you.  Or if you have shell access, such as on a VPS, you can perform it without involving your host.  It’s just way too important in my book to initiate a backup via a browser initiating a script and streaming contents back to me.  Script timeouts, network anomalies, etc., just too many things to go wrong for such a large amount of data.

Gotcha, Sue.

As for Derek’s point, makes sense, I can start using mysqldump.