Missing messages in backup-file

[serge M]

SMF 1.1.12 on MySql 4.0

Friends,

I had a data-loss recently in my Sql. I have made regular backups so I tried to import it into the Sql. It seems as if the
messages are missing in the backup. The forum had about 90 thousand posts and the backup file sql.gz (made through
the admin panel) has 1.86 MB. I made a new database with the original structure, imported the backup-file and all
that I found was ad-man data. The messages are completely empty. Opening the sql file in a text-editor does not
show the messages, so I presume they are not in the file.

Am I doing something wrong or is it possible that the messages are not in the backup-file? Is the size of the backup-file
correct?

[Kindred]

how did you generate the backup file?   because it certainly sounds like you do not have the messages in that file, with the small file-size

[serge M]

I downloaded the backup-files through the forum administration.

Technical service - Back-up copy of Database (Sorry I am not using an english version of the forum, so I just translated
the function in the admin panel, the name in the english version might be slightly different).



I never payed attention to the back-up file size, I just made the back-up copies and thought I am safe for the case.

Now I have the case and... What happened?

[serge M]

friends, as this is logically an important item, I kindly ask you to advise me what to check, how to make
proper backups, what to do.

if I will not be able to do proper backups in smf, I will have to think about changing the system.

[Baby Daisy]

Click all those checkboxes when making the backup

[DavidCT]

Personally I generate my backups through Cpanel's "backup".  I heard SMF's backup was suspect at times.

1.86M sounds like it should have some messages in it, though not 90K worth, though I suppose you could have many PMs or log errors.

Cpanel also has a MySQL area which you can check the DB for errors.

Ask your host if they make backups - if you have a good one, maybe they have a  DB saved

[JimM]

Once the database reaches the size of yours, you will not be able to use the admin panel to download the backup.  Here is a file that has some good info about different ways to backup your database.

[Tutorial] ''How to backup&restore  your forum  in several different ways''

[tumbleweed]

Once the database reaches the size of yours, you will not be able to use the admin panel to download the backup.  Here is a file that has some good info about different ways to backup your database.

[Tutorial] ''How to backup&restore  your forum  in several different ways''

Does SMF have a warning about possible errors when downloading large DB. If not a strong warning should be placed in that area.

[serge M]

Thank you a lot for the feedback friends. If I only would have known earlier ...

[Illori]

Once the database reaches the size of yours, you will not be able to use the admin panel to download the backup.  Here is a file that has some good info about different ways to backup your database.

[Tutorial] ''How to backup&restore  your forum  in several different ways''

Does SMF have a warning about possible errors when downloading large DB. If not a strong warning should be placed in that area.

no it does not, maybe a feature request should be made to include a warning about this.

[JimM]

Just as Illori said, it does not.  There have been some discussions related to this issue but so far no clear path as to what the solution is.  Suffice it to say, it is on the list.

[MrPhil]

You're probably best off using phpMyAdmin or some other database tool to make backups. I've heard too many horror stories about SMF's built-in backup system to trust it. And don't rely on a hosting service to be your exclusive backup method -- sometimes they make mistakes too. Use their backups only as a backup to your backup practices.

At a bare minimum, you need the backup to contain the data from all your tables. This would be in the form of "INSERT" commands for all the records (rows of data, and one INSERT can deal with multiple rows). Make sure all your tables are accounted for, and all rows appear to be recorded. It's generally good to include the table structure (CREATE TABLE commands), so that you don't have to manually set up the tables. Many backups will include commands to DROP old copies of the table and CREATE new ones, or TRUNCATE (empty) existing tables and re-use the structure. In any case, you should understand what your particular backup is doing for you, so when you need it, it's not panic time (you'll know what manual steps you'll need to take). Finally, a backup may be compressed to save space (e.g., zipped), but this is not mandatory. Just make sure you know how to uncompress it so you can see inside.

No matter what method you use for backing up your database, periodically take a look at the backups and make sure that they contain all the expected data. You don't want to be in the unfortunate position, as far too many people on far too many systems (not just SMF) have found themselves, that your backup is useless because it's missing tables or is corrupted or was never written! I've seen system administrators make a fetish of showing how conscientious they are about doing a weekly backup and storing the tape cartridges in a fireproof safe, never dreaming that all their tapes were write-protected and were all blank. And remote systems (such as your hosting system) can change over time, leaving you unaware that something has changed and your tried-and-true backup methods no longer work! That's why you have to periodically check your backup process, even if it was initially working perfectly.