View Full Version : Solved Database backup file too big!

22-06-10, 09:23
I backup my forum once a weak through ssh, my backup was no bigger then 350mb and now it hit 1.2gb, I think this might be problem meaning I don't have problems backing it up but if I ever have to do a restore won't the server timeout with such a big backup??

22-06-10, 12:00
I backup my forum once a weak through ssh, my backup was no bigger then 350mb and now it hit 1.2gb, I think this might be problem meaning I don't have problems backing it up but if I ever have to do a restore won't the server timeout with such a big backup??

I suggest you check these guys out Remote Backup using Rsync or FTP (http://www.bqbackup.com/) We have used them for a few years and currently backup about 1TB daily, it is very easy to set up. You can obviously go through some bandwidth, but that may or may not be a problem depending on your server plan.

I'm not an expert, someone else here no doubt has better advice. Its important to not rsync live databases, instead rsync your hotcopied backups ( google it ) (http://www.google.com.au/search?hl=en&q=mysqlhotcopy) or a SQL dump or your control panel backups.

Restoring is as simple as using rsync or SCP to move the backup back to your server (bqbackup give you shell access) and restore the database the appropriate way for your backup method. 1.2GB should be restored in a few minutes.

That said, a decent host should give you all the tools you need to manage every backup task.

22-06-10, 17:14
Thanks for responding but as I can see you have a big outfit so you can handle the assisted servers + extras on the other hand I have about 140k members 400k posts & etc so I consider it to be a small/medium forum.

I'm very handy in SSHing so the problem isn't there nor with my server (specs are good) none the less I see a "potential" problem in restoring it due to its humongous size (and growing) with server timeouts and so forth.

I think some type of compression method should be implemented and/or tables in MyAdmin reduced in size (number wise), even optimizing my database has become a hateful thing to do since it's all time taking and there's very little of it.

Best Regards :p

22-06-10, 17:26
On our server we use automatic full server backup (vps functionality). Without any issues.

Please consider not include vBET cache tables in backup. You can easily determine which tables you want to cache by MyAdmin so I guess that it can also be done from command line (by ssh). Of course such command will be very long, basing on number of vBulletin tables, but if you save it to some file it should be quite comfortable way to do backups.

Please note that using vBET your content is multiplied 52 times. So if you have cache turned on your DB have to grow up. And not just a little ;) You can avoid it by turn off cache, but we strongly do not recommend it. For big forums asking each time Google for translation would kill your server performance or even finish with Google restrictions.

22-06-10, 17:48
When I purchased my dedicated server (along time ago) there was no such thing as VPS :)

I know how to use SSH very well and it's near/if not impossible to exclude vBET from being backuped, the only thing that one can do is esclude it when optimizing or repairing.

But you must consider that a good 50% of the webmasters (no offense meant) are on shared or virtual dedicated server and about 70% don't know what SSH is thus relying on mySQLdumper, the built in vBulletin backup and/or similar.

22-06-10, 18:00
Those who use shared hosting do not have issue wit big databases. I see no possibility to run huge vBulletin forum - even without any plugins - on shared hosting. The resources are simply too low.

Also as I wrote those who do not use SSH can simply backup their databases i.e. by phpMyAdmin where they can determine exactly which tables have to be backed up. Also you can try it. In your case truly I expect some issues because of large files to upload by such phpMyAdmin, but maybe there is some option so save it on server not upload. Please check it. Also - I believe in your backup experience, still if some GUI tools allow to determine which tables exactly have to be backed up, I expect that is should be also allowed by command line. I do not know that - as I wrote we have no issues at all with backup whole of server - but I expect it, because most of GUI tools like that are just fasades and on the bottom are used just command from command line. So maybe it is just worth to check - maybe it was added in some MySQL version. I know that phpMyAdmin supports it.

19-07-10, 15:36
how can we have vbet tables on a different db just for vbet

20-07-10, 13:11
please, ask about it in new thread :)

20-07-10, 19:03
tsak76. I second that******

AfrikaansAlbanianArabicBelarusianBulgarianCatalanChineseCroatianCzechDanishDutchEnglishEstonianFilipinoFinnishFrenchGalicianGermanGreekHaitian CreoleHebrewHindiHungarianIcelandicIndonesianIrishItalianJapaneseKoreanLatvianLithuanianMacedonianMalayMalteseNorwegianPersianPolishPortugueseRomanianRussianSerbianSlovakSlovenianSpanishSwahiliSwedishTaiwaneseThaiTurkishUkrainianVietnameseWelshYiddish
Translated to other languages supported by vBET Translator PRODUCER_PRODUCT_VERSION