Last modified: 2010-05-15 15:59:46 UTC
The dumpBackup.php either does not backup these pages:
There may also be other pages it is not backing up. Since these are pages that are almost always changed, not backing them up is a problem. The dumpBackup.php seemed to backup all my NEW Pages. The importDump.php script worked well with the xml file created by the dumpBackup.php, but since dumpBackup.php failed to import the above pages, the importDump.php did not import them.
I tried both --full and --current options and neither backed up the above pages.
Perhaps there is an undocumented method to include the above pages in the dumpBackup.php process?
All such pages are included.
Perhaps you imported your complete XML dump into a wiki which already had these pages, and the imported versions were subordinate?
The pages are NOT exported to the dumpBackup.php's XML file - so importDump.php will never get these pages. The bug is that the dumpBackup.php should backup all of the pages in the wiki; or at least there should be a list of the pages that it will not back up so those pages can be Exported using that facility in the Wiki site itself.
Since I am the one that set up my MediaWiki, I know which pages are changed. The dumpBackup.php worked well for the Pages I created, but not for the Pages that were in the Default Wiki installation (even though I changed these). I like how the utility is not Database Dependent; i.e. I changed to a database with a different database name. I do not thing the mwdump java utility or the MySQL backup procedures can do this.
I am certain that other people would use the dumpBackup.php script if they would be sure that all the pages would be exported. From searching the web for how to resolve this issue I discovered many people are concerned about adequate MediaWiki backup and restore procedures.
It is definitely a bug that dumpBackup.php does not back up at least 5 critical pages; and maybe skips other pages.
I do not think that this should be difficult to fix because it appears to be more of an accidental omission rather than broken code. Perhaps the programmer may have "commented out" the code to backup these pages while testing and then forgot to enable that code for production.
It is common sense that a backup that skips unspecified data arbitrarily and unexpectedly is not usable. If skipping changed pages is the intended behavior, then the criteria the dumpBackup.php is using to decide what to backup should be documented - even if it is in a readme file in the maintenance directory. Maybe I'm old fashioned, but I think it is really important to do backups AND to know what is being backed up.
***dumpBackup dumps ALL PAGES IN THE DATABASE, unless you pass a specific list of pages to dump.***
Please confirm that your database is not corrupt and that your database and your output file both contain what you think they do.
Ok, I double checked by reinstalling a new server from scratch (Ubuntu 7.10 Server w/ LAMP)
The dumpBackup XML contains all the changed pages, including the Main Page and Privacy page. After importDump I don't see the new pages.
Looking back at your comments, I see the
"Perhaps you imported your complete XML dump into a wiki which already had these
pages, and the imported versions were subordinate?"
Looking at the Hitory for Main Page, I notice that the imported version is displayed as a "Previous" version. If I login, I can "undo" default version to restore the import version.
I can live with this because it is consistent and predictable behavior. Thinking about it, it is probably desirable that the system works this way for migration purposes; for example: when importing a dump into a newer MediaWiki version.
Thanks for your patience in helping me understand this!