I use the FUD-forum in three different applications. One of the applications use the forum as a data file repository, with many very large attachments. I have also used a slow computer as the server; in fact, the server computer did not have any CPU-fan. |
My first update is to list every file saved in the backup on screen. The issue was that the browser disconnected from the server during backup, after waiting several and many minutes for the "data" backup. The browser need the server to regularly print a char to show that it is still operating, and my solution was to modify "adm/admdump.php" to print each file name. The largest single attachment is not large enough to stall the backup until time-out.
Backup and restore is often associated with various crashes, and a detailed printing of included files is helpful.
Next issue is that the standard script don't backup all things. If you made any modification, or added files and directories, this is not included in the backup. It is very easy, however, to include these extra directories.
The backup install script rebuild the site using the Themes. Unfortunately one of my applications use the main page to display a status page from an external software/hardware. My solution is to include the WEBB/theme directory in the backup, and remove the rebuild of the Themes, that erase the modification. It would be nice if I could include the modification before the Themes is built, but I have not been able to find the correct file/spot, as it should glue itself in between parts in the end of the page.
The install-backup script "adm/admimport.php" is not very forgiving, and will typically abort completely on any error. This will leave your site without files and without a database. My guess is that you administrator account will be missing too. Unfortunately some of us may have limited access to the Server, and you will need a forum-files backup and a database backup to restore a working version of the forum. A backup routine is a boring thing until you need one. It would be moderately difficult to temporarily include an extra log-in, that is in a php file and do not use the database, to allow a restart of the backup-restore-script admimport.php
My exact problem was in the "fud30_calendar". Some completely unknown holidays "Cinco de Mayo", "Veterans Day", "Second day of the month, do your time sheets." is registered as NULL, NULL, NULL; and the import value-check of the database don't like this on import. So it bug out with an error!
I don't use the calendar, and deleting these lines from the database using phpMyAdmin, and rerun the backup script on the undamaged forum solves the problem. And if you don't have an undamaged forum to run a new backup on, but really have a problem, then you need to edit inside the backup file.
A better solution would be to have the backup-restore script to skip over small errors, but this could also fail in case the error is not small, it could be the admin account that don't install in the database.
The "adm/admimport.php" also include a little line
if ($path == 'WWW_ROOT_DISK/adm/admimport.php' )
// Skip admimport.php, don't overwrite the running script.
and this little exact-match have to be written
if ($path == 'WWW_ROOT_DISKadm/admimport.php' )
if it shall catch the import script, and not overwrite itself during backup-reload, which can be dangerous. My solution is to use
if ( substr_count( $path, 'admimport.php') > 0 )
$path = $path . '.orig';
pf('Restore File '. $path );
which print the import file using a safe name admimport.php.orig and also, on the bottom line, print a list of all unpacked file names, so you can check there are all there. Manually.
So, I now run an a new server, that has these DDR2-RAM and also a fan ontop the CPU. I am not surprised of the backup-and-restore problems I found, but some small changes could save hours in case there is a small glitch.
You shall also note that I run 3.0.3 version of the forum.
A "recover.php" that check for secret code and enable a restart of the backup-restore-process.
Backup all the files. Backup from the roots, and all subdirectories. Do not mess with a backup of only "necessary" files.
Restore the database one table at a time. If there is an error, print the backup to a text file, and skip to the next table. Possibly can the error be corrected in the database or in the text file, then you can install the table using a little cut-and paste in phpMyAdmin.
Remove the automatic "rebuild themes" in admimport.php
Check that the php script is allowed to write the files before it runs, check with one file in the DATA directory, one file in the WEBB directory, and create a temp table in the database.
I will, in future, keep also an ordinary files backup of my server, as a complement to the FUD-forum backup (modified).