Two types of things in a standard Tiki installation must be saved for a backup of your specific site:
Backup your MySQL database. (see below for examples)
Backup your files.
Copy via FTP your entire folder where Tiki is installed (and all subfolders)
Make sure to also backup your files that are outside the web directory (if you set up your Tiki this way)
More detailed instructions
- Related links
Adminer (formerly phpMinAdmin) is a full-featured MySQL management tool written in PHP. Conversely to phpMyAdmin, it consists of a single file ready to deploy to the target server.
Eventually, you could get phpMyAdmin software to install it yourself: http://www.phpMyAdmin.net/
The main screen in phpMyAdmin looks like:
(screenshots are taken using the TikiLiveCD: http://tiki.org/TikiLiveCD)
Select your database from the list (tiki19 in this example; tiki_1 in screenshot below), at the drop down from the left column of the screen. You will see then something like:
Click on the tab that says SQL (or Export, in newer versions of phpMyAdmin):
At the export screen, make sure that you check the box from the section “Structure”, that says “Add DROP TABLE”, since it will be much easier the process to re-insert a backup later on from this same database that you are now exporting.
The rest of options are ok as seen by default.
At last, select the box “send”, and click on the button “Execute”. You will see a dialog menu like this one:
Save it on disc at your preferred location.
We will now open it to check that everything is all right (and to let you show the type of file saved, if this is new to you):
The file has to be encoded in utf-8. If we want to change the character set to, for instance, iso-8859-1 (to be able to edit it with most MS Windows applications that didn’t cope well with other charsets different from that default), we can do it direcetly from true “utf-8 enabled” editors (see ToolBox pages for links on common applications to do that depending on your operating system). For instance, using KWrite, on GNU/Linux, it would look like:
Basic command (this will make a date and timestamped gzipped dump of the database in /path/to/backups/)
php console.php database:backup /path/to/backups/
Format the backup file name, this example will only use the year, month and day in the output file name.
php console.php database:backup /path/to/backups/ Y-m-d
Add a cron command to do this to create an hourly backup which will overwrite yesterday’s ones 24 hours later
cd /home/tiki/public_html; php console.php database:backup /home/backups/hourly/ H00 >/dev/null
Write a command like:
mysqldump --opt -u user -p tiki12 > tiki12_backup_yyyymmdd.sql
In your case, change in the example above:
- --opt is to use common options for mysqldump
- user for your username at the MySQL server
- -p will prompt you for the password
- tiki12 for your database name, and
- yyyymmdd for the four digits of the year, month and day, respectively, for instance, to have your backups easily sorted by name and date of creation also.
Then, save your backup copy in a safe place. It’s recommended to send by ftp or sftp that file to your local computer to prevent problems if server harddisk and backups fail at any time.
To restore, please see: Import Database
http://www.phpmybackuppro.net and modded 1 line of tiki-login: including a call of the scheduled backup script of pMBP. Now I get my daily gzipped backup of the Database delivered right into my mailbox.
phpMyBackupPro has also a feature for directory backup per FTP; I’ve not yet tried it for attachment and gallery folders located outside of www root.
I included the backup feature into the Login script because only logged users can post on my site - thus the script is only called once for every user, and performance is only slightly affected by the first user each new day who triggers the daily backup (has to wait some seconds until the backup is finished). If nobody logs in there’s no need to update the last backup.
The problem: A PHP script has a maximum execution time that is usually set to 30 seconds on most server installations. A script running longer than this limit will simply stop working. This behavior makes backing up large databases impossible. Maybe you already had this specific problem when using other tools. MySQLDumper fills a gap …
The restore process is similar. Unlike other tools, splitting and splicing of large backup files is no longer necessary.
MySQLDumper can write the data directly into a compressed .gz file. The restore script is able to read this file directly without unpacking it. You can also use the script without compression, but using Gzip saves a lot of bandwidth. You can even configure the script to automatically send the backup file to an FTP account or your email address.
Get it on http://www.mysqldumper.net/.
Import database for more details.
TRIM, which backs up both files and the database.