Help with db plz

[TECK]

Do this. In your /install folder, there is a file called mysql-schema.php.
Inside you will find the the name of each table vBulletin creates.
Then, download from your /backup folder the latest file carying the name of each table.
Import them into a test board, to see if you can restore properly the users database and threads. I hope you will not use phpmyadmin or any similar web tools who only help you destroy your database.

Pretty sure it will not work properly, since they are files generated by a vb hack, not real SQL backup files. Let's hope you will succeed, I really wish you good luck.

[Marco van Herwaarden]

"04/01/2007 " is 4th january or 1st april?

How many files do you have for each date (ie. Live-2007-03-27*).

If they have a .sql extension then they are probably table dumps, 1 file for 1 table. You will probably only need to restore the files of 1 date.

[Daja]

Thank you guys all for the help.

Marco the backup thay had was 4 january :S, if it was april it would have been great.
The folder date 2007-03-27 has over 1200 files, the dates before this looks like thay got less.
You right they are table dumbs, i opend a few and i can c thred titles posts etc etc, but the thing is i DONT know how to restore this files of the latest date,and have the forum back to work.

[Marco van Herwaarden]

Please PM me login for your AdminCP and FTP, and i will see if i can figure it out.

[TECK]

Good idea, Marco is part of the support team so he should be able to help you better while looking at the actual files.
1200 files, is crazy...

Marco let us know here how those files were generated, so we know if it was a hack.
In this way, we have a reference for others. Thanks.

[Marco van Herwaarden]

Ok i had a look, and you will not really be happy with what i found:

You currently have the following databases under your account:
- forum (0 tables)
- forumi (1 table, vBulletin datastore)
- wbb (58 tables, vBulletin tables until the postindex table)

On your FTP in the directory 'backup' there is a directory for each date that a backup probably has ran. The directories are named by date.

Each directory contain files named: 'Live-' + Date + <tablename> + .sql
Each file contain a regular dump of a single table: Create statement and inserts for the data. This should be enough to recreate a table.

Most backups however seem to be incomplete, some have more tables then others, but a quick look around did not show any table with a name higher then 'postindex'. (so this means that tables like setting, thread and user are not in these backups ).

The latest backups do have a lot of tables, judging on the 'Live' in the name of these files, i am guessing that this was the name of your database, or the name of a modification/server script that generated them.

The backup dated 2007-03-27 contain a total of 1555 table dumps, with again postindex being the last one. It seems that you had more then 1 product installed in this database, each with their own prefix. Some i see are:

- No prefix: vBulletin tables
- cms: Probably a CMS you where using
- exv2
- ibf
- mkp: MKPortal?
- nuke: phpnuke?
- php: phpBB?
- phpbb_: phpBB?
- phpbb: phpBB?
- phpb: phpBB?
......

The bottom line: none of the backups seem to be complete, and therefor useless.

The latest maybe complete that i found is dated 2007-01-27

I looked at the table dump of the 'product' table (2007-01-27) to see if you had any backup type modification installed into vBulletin and i did see:

INSERT INTO `product` VALUES ('paulm_20060710','Auto Database Backup','Cron based automatic backup of vbulletin database.','2.12','1','https://vborg.vbsupport.ru/misc.php?do=producthelp&pid=paulm_20060710','https://vborg.vbsupport.ru/misc.php?do=productcheck&pid=paulm_20060710');

So that is very likely the modification you used to create your backups.

[TECK]

Thanks for the detailed info, Marco.
That should teach all how important is NOT to make backups using any tools other then mysqldump.

If you are not familiar with the procedure, do this:
Telnet into your server and run this command:
mysqldump --opt -u USERNAME -p DATABASENAME > /path/to/backup/folder/$date.sql

Restore your database with:
mysql -u USERNAME -p DATABASENAME < /path/to/backup/folder/070101.sql

Or you can set a daily cron job, for backup.sh (with contents like):
#!/bin/sh
date=`date -I`
mysqldump --opt --all-databases | bzip2 -c /var/backup/database-$date.sql.bz2

Personally, I do this and transfer every week all files from my server into my Windows PC, through Samba.
I'm really sorry about your problem, but look at it positivelly... you will never miss to make a backup from now on, the right way.

Also, this thread really proves one more time how unreliable are web backups.
I said it many times: Never do a backup through a web interface.
People who release backup hacks should warn the users that their tools have 99.99% chances to produce corrupted backups, no matter what's the size of the database.

[Paul M]

Originally Posted by TECK

Thanks for the detailed info, Marco.
That should teach all how important is NOT to make backups using any tools other then mysqldump.

That is nothing more than your opinion, it is not a fact.

He was indeed using one of my modifications to create backups each night, the very same one I use to backup my forums (without any problems).

The important mistake he made was never checking his backups - how you create them isn't that important (and web based methods are perfectly acceptable) - what is important is that you check them, and better still do a restore every so often to a test database, to make sure everything works.

Originally Posted by TECK

People who release backup hacks should warn the users that their tools have 99.99% chances to produce corrupted backups, no matter what's the size of the database.

What complete and utter nonsense. Please don't make ridiculous statements like this again.

[Daja]

Ok thank you very much all of you for the help and doing ur best. Thanks egain.