Just an overview....

For a backup of an ez3 (or ez2) system, you can use the backup-script " reoback".

Backup

1. (for ez2, optional:) Call your cron-job to do a session cleanup and so on, thus minimizing your session* tables in the DB
2. Do a backup of your Database. For MySQL, we use mysqldump to dump one ez Database into a text file.
3. Use reoback to backup your complete ez3 directory, the database dump, that was created by mysqldump and maybe your Apache configuration. This should give you one nice tar.gz of your site.

Restore

Reverse the backup process :

1. Unpack your tar.gz to re-create the files
2. re-recreate your database by importing your DB dump (like mysql my_database if necessary, restore your apache config (httpd.conf) and restart your webserver

General Notes:

• For consistance's sake, try to backup the files at the same time or directly after the database.
• Reoback can be used to copy or move your backup files to some other server using FTP or NFS. I would recommend this. If you don't have some other server/webspace, that you can FTP to, you need to download the backup files to some client (probably manually, except your client is running all the time). Beware of huge files!
• Reoback can be used to do incremental backups.
• This process can be used to port/copy/clone any ez site. Just restore to some other place/server and adapt your .ini's.
• Of course, you should automate the process by using the server's cron system and some small Perl scripts.

PS: Can any MySQL guru please comment, if mysqldump really is the best choice for doing a consistant dump (=is the DB locked)? Regarding mysqldump: If you use the -l or --lock-tables option when using mysqldump, it will lock all tables in a database (not across all databases, just one at a time). There's also the --add-locks option which will lock each table separately but it does not guarantee consistency across a database.

<li>if necessary, restore your apache config (httpd.conf) and restart your webserver</li></ol>General Notes:<ul> <li>For consistance's sake, try to backup the files at the same time or directly after the database. </li> <li>Reoback can be used to copy or move your backup files to some other server using FTP or NFS. I would recommend this. If you don't have some other server/webspace, that you can FTP to, you need to download the backup files to some client (probably manually, except your client is running all the time). Beware of huge files!</li> <li>Reoback can be used to do incremental backups. </li> <li>This process can be used to port/copy/clone any ez site. Just restore to some other place/server and adapt your .ini's. </li> <li>Of course, you should automate the process by using the server's cron system and some small Perl scripts.</li></ul>PS: Can any MySQL guru please comment, if mysqldump really is the best choice for doing a consistant dump (=is the DB locked)?<strong>Regarding mysqldump</strong>: If you use the -l or --lock-tables option when using mysqldump, it will lock all tables in a database (not across all databases, just one at a time). There's also the --add-locks option which will lock each table separately but it does not guarantee consistency across a database.</paragraph></sec
if necessary, restore your apache config (httpd.conf) and restart your webserver

General Notes:

• For consistance's sake, try to backup the files at the same time or directly after the database.
• Reoback can be used to copy or move your backup files to some other server using FTP or NFS. I would recommend this.
  If you don't have some other server/webspace, that you can FTP to, you need to download the backup files to some client (probably manually, except your client is running all the time). Beware of huge files!
• Reoback can be used to do incremental backups.
• This process can be used to port/copy/clone any ez site. Just restore to some other place/server and adapt your .ini's.
• Of course, you should automate the process by using the server's cron system and some small Perl scripts.

PS: Can any MySQL guru please comment, if mysqldump really is the best choice for doing a consistant dump (=is the DB locked)?

Regarding mysqldump: If you use the -l or --lock-tables option when using mysqldump, it will lock all tables in a database (not across all databases, just one at a time). There's also the --add-locks option which will lock each table separately but it does not guarantee consistency across a database.