Support/Comments for BkupMODx

Quote from: Chuck at Aug 25, 2008, 09:24 PM

• 3) Do not overwrite the existing bkup_config file during the unzip process

Users should be aware that the MODx mode (mysql = 3) should not be used in a restore process. The MODx information could be damaged, that’s why you want to perform a restore, right?

So, would it be an idea to display an error message in that case or, perhaps even better, ask for host/user/password?

I really think this would make BkupMODx even a greater tool and a big help in case of emergency! I wish you luck creating this

Quote from: WeBe at Aug 26, 2008, 10:19 AM

Users should be aware that the MODx mode (mysql = 3) should not be used in a restore process. The MODx information could be damaged, that’s why you want to perform a restore, right?

So, would it be an idea to display an error message in that case or, perhaps even better, ask for host/user/password?

I really think this would make BkupMODx even a greater tool and a big help in case of emergency! I wish you luck creating this

Good catch! It’s funny you mention that because earlier this morning I added additional file_exists checks for both the BkupMODx bkup_config.php and the MODx config.inc.php files. These checks should help accomplish the same objective.

If a restore is attempted with mysql=3 and MODx is not already installed then the script will fail when it looks for the MODx config.inc.php file and display an error. The user will have to change to modx=2 and add the host/user/pass in the bkup_config.php file for the restore to proceed. That should also help reinforce the need to create the dbase(s) prior to the restore.

If a restore is attempted and MODx already exists on the restore system that changes the game again. If the bkup_config.php values are different on the restore system from the backup system then the values on the restore system have to be used. That’s why the bkup_config.php file can’t be overwritten.

This is a big feature to add and I’m not expecting it will release until sometime in early September. I’m avoiding input forms for the time being just for KISS reasons. If you think of any other gotchas let me know.

Website Backup and Restore: A Disaster Recovery Tool

v2.0 just released!

With this release the script evolves into a disaster revovery tool with the addition of zip extract and sql import functions.  There are too many changes to recap in the script but some of the major changes are:

• Elimination of the tmp directory and use of the archive directory for the sql dump files.  This makes for a more comprehensive Archive screen and the ability to reuse code to handle multiple file types.
• Replacement of the PclZip class with a customized zip.lib.php class.  The new compression class is smaller, quicker and doesn’t throw the kitchen sink at a simple zip task.
• Elimination of the no compression option.  Since the script memory requirements appear to be minimized this option is no longer needed.
• Enhancement of the interface for both the Backup and Archive functions.  A little collor added to break things up and more action confirmation prompts.

Here’s the official list of changes:

* Added restore zip and import sql functions

* Improved Backup process

* Improved Archive process

* Renamed menu functions

Upgrade and new installation instructions in README.txt.

Enjoy!

Looks like a great addition to MODx.

I haven’t used it, so this is probably a dumb question, but what’s necessary to backup and restore a remote install where everything on the remote site is gone (or trashed) assuming that the backup was executed before the crash, of course?

Quote from: BobRay at Sep 10, 2008, 06:17 PM

Looks like a great addition to MODx.

I haven’t used it, so this is probably a dumb question, but what’s necessary to backup and restore a remote install where everything on the remote site is gone (or trashed) assuming that the backup was executed before the crash, of course?

• Install & config BkupMODx
• Recreate the MySQL database if required
• Make sure the base path writable by the web server
• Copy the zip file into the archive
• Extract the zip
• Import the sql dump
• Reconfig MODx if required

What did you base the custom .zip library off of, if you don’t mind me asking. Are there any requirements or is it purely standalone?

Quote from: rthrash at Sep 10, 2008, 09:17 PM

What did you base the custom .zip library off of, if you don’t mind me asking. Are there any requirements or is it purely standalone?

It’s based on the zip.lib.php file found in phpMyAdmin libraries directory. I’m not sure where it originally came from but here’s the embedded message.

/**
* Zip file creation class.
* Makes zip files.
*
* Based on :
*
* http://www.zend.com/codex.php?id=535&single=1
* By Eric Mueller <[email protected]>
*
* http://www.zend.com/codex.php?id=470&single=1
* by Denis125 <[email protected]>
*
* a patch from Peter Listiak <[email protected]> for last modified
* date and time of the compressed file
*
* Official ZIP file format: http://www.pkware.com/appnote.txt
*
* @access public
*/

Quote from: Chuck at Sep 10, 2008, 07:27 PM

Quote from: BobRay at Sep 10, 2008, 06:17 PM

Looks like a great addition to MODx.

I haven’t used it, so this is probably a dumb question, but what’s necessary to backup and restore a remote install where everything on the remote site is gone (or trashed) assuming that the backup was executed before the crash, of course?

• Install & config BkupMODx
• Recreate the MySQL database if required
• Make sure the base path writable by the web server
• Copy the zip file into the archive
• Extract the zip
• Import the sql dump
• Reconfig MODx if required

Sorry, still confused. Which of these steps are occurring on the local machine and which on the remote?

Quote from: BobRay at Sep 10, 2008, 10:51 PM

Sorry, still confused. Which of these steps are occurring on the local machine and which on the remote?

It’s all remote/server based. Nothing needs to be done locally.

Quote from: Chuck at Sep 10, 2008, 10:56 PM

Quote from: BobRay at Sep 10, 2008, 10:51 PM

Sorry, still confused. Which of these steps are occurring on the local machine and which on the remote?

It’s all remote/server based. Nothing needs to be done locally.

But, if the remote server crashes or is hacked, there’d be nothing to back up from (unless the backup is automatically saved on the local machine -- is that it?).