It's better when it's simple

User Tools

Site Tools


BackupTool for DokuWiki

Compatible with DokuWiki

  • 2018-04-22 "Greebo" yes
  • 2017-02-19 "Frusterick Manners" yes
  • 2016-06-26 "Elenor Of Tsort" yes
  • 2015-08-10 "Detritus" yes

plugin Backup your site and configuration data to a file.

Last updated on

Similar to zip

Tagged with archive, backup, maintenance


It's not required, but please consider linking to this page or the main page from your site if you like this product.


As with any data backup tool, there is always a possibility for unintentional data loss.

Neither I nor this site will be held responsible for any data loss caused by this product.

So download and use at your own risk!

:!: If you select “Backup method: “PEAR Archive Library” and receive “Fatal error: Call to undefined method PEAR::_Archive_Tar() in /usr/local/php5_6/lib/php/PEAR.php on line 219” (or similar, depending upon which version of php you have installed), verify that you have the PEAR module installed (e.g., I don't believe that “GoDaddy” includes the PEAR module). Alternatively, if you select “GNU Tar (filtered)” or “GNU Tar (fast; unfiltered)”, your backup should work fine.


Before downloading or using this product, make sure you understand and accept the terms of the license.

After downloading, make sure to follow the install instructions or upgrading instructions below; trust me, they're worth reading.

  • Older downloads are available on request only.

Note: always points to the latest stable version!


Use the Extension manager to search and install, or alternatively…

  1. download the tarball/zip-file
  2. unpack it into <dokuwiki>/lib/plugins/
  3. login as admin and change the plugin in the configuration manager

using git:

% cd <dokuwiki>/lib/plugins/
% git clone git:// backup

Debian install (or probably any other distribution):

# cd /usr/share/dokuwiki/lib/plugins/
# wget
# unzip
# chown -Rv 33 backup/

Note: always points to the latest stable version


This is a plugin for DokuWiki which enables you to backup the most important parts of your site; this includes all of your pages, all old revisions, meta data, subscriptions, media files (your downloads), as well as your plugins and templates.

This is in case, for some odd reason, your host accidentally loses all your files; it's happened to me personally twice, on two different hosts since I began using DokuWiki– and backing up manually can be quite a nightmare.

Standard Features

To access the plugin, make sure you're on the admin account, and click the admin button on your wiki site.

An entry named “Backup Tool” should be listed in the the available administrative tasks. Click it, and you should see something like the following image below:

Simply check the items you wish to backup, and uncheck the ones you don't. For instance, you may not care about old revisions of documents, so you don't have to include them if you don't want to.

Click the Create Backup button, and the process of backing up starts. For large sites, it may take some time; it may even time out– in which case you may wish to backup each section individually– though this is unlikely. It will usually take at least a little time for the page to respond, so please be patient.

The backup file is generated and put in the root of your media directory. So you're then able to download it from there, and you may wish to delete it afterwards.


As a plugin all you need to do is unpack the file into the lib/plugins/ directory (you should end up with a lib/plugins/backup folder.)


To upgrade, remove the original lib/plugins/backup folder, and install the new version as instructed above.

What's New

June 28, 2016

  • Apparently a new release of DokuWiki, their version 2016-06-26, broke the existing plugin. Luckily a user on github, dsp777, was able to come up with a fix for it; so the issue should be resolved, and thanks, dsp777.

August 28, 2014

  • Added Japanese language support.

May 19, 2014

  • Updated

October 09, 2013

  • Fixed broken function usage after they were removed with the Wheaterwax update
  • Added German language support, though, still needs some clean up.

April 27, 2011

  • Fixed mkpath and made it respect conf[dmode].

March 16, 2009

August 24, 2008

  • New backup method: “Lazy and Quick” method. This method runs in O(1) constant time rather than the other two methods that run in O(n) linear time. This method should be used for folks with big sites to back up, but is only available if the GNU Tar method is supported.
  • For folks with installs on Macintosh based servers, files named ”.DS_Store“ and files beginning with ”._“ will be excluded from PEAR and GNU Tar methods now.
  • Some minor tweaks to the language files.

August 2, 2008

Major update!

Here's what's new:

  • I've made an effort for all run-time errors to be handled.
  • I've replaced shell_exec with just exec, since this is more appropriate for the command line version.
  • PEAR is now supported as an alternate to exec, thanks to Andreas Wagner for this.
  • The list of files to backup is much improved, again thanks to Andreas Wagner.
  • Backups will not archive existing backups, again thanks to Andreas Wagner.
  • I've added auto-detection of PEAR and/or exec availability, since not all users will have access to these.
  • You can choose between PEAR and exec if you have the option of both.
  • All files entries for the exec version are relative instead of absolute now for exec, thanks to Uwe Koloska for this.
  • Both backup methods generate the same file structure now as well.
  • Backup file names have changed slightly, files now start with “dw-backup-”.
  • Backup options selected are now saved as defaults for future sessions.
  • Compression options are chosen based on what's available, in the order of bzip2, gzip, and no compression for both PEAR and exec.
  • Backup files are created directly into the media directory, so no moving is necessary.

July 10, 2008

I've finally gotten time to check the new ACL compatibility.

As it turns out, I was mistaken– ACL file names and structure have not changed, simply the interface to modify ACL has, and this does not affect backuptool for DokuWiki at all.

Therefore backuptool for DokuWiki will work regardless of the DokuWiki's version.

So in other words, the April 7, 2007 version will work, and is safe to use.

April 5, 2007

  • Backup files are now timestamped with date and time, thanks to Syv Ritch for the push.

March 11, 2007

  • Added conf/mime.conf to list of things backed up under “configuration settings”

October 12, 2006

  • New BackupTool release, fixes compatibility with new DokuWiki versions.

August 3, 2006

  • Internationalization support complete

July 29, 2006

  • Initial release


Note to users: Tarlib doesn't work!

Hi everyone, let me state for the record that “tarlib”, which is part of DokuWiki's core, currently does not generate working tar files in all situations.

I've discussed this on the DokuWiki mailing list several times, and have filed (if I recall) at least two bug reports about it.

  • The latest bug report I've filed is here→ Bug fixed.
  • The latest mailing list discussion for this is here.

Tarlib version (non-working)

Here is a version that attempts to use tarlib (part of DW) to write the archive directly into the media folder. The tar file it creates for some reason seems to be corrupt (or at least it won't verify in my local archive manager, 7-zip.) I suspect it's either:

  • Checksum generated is incorrect
  • Format is otherwise incorrect
  • Possibly DokuWiki's version of tarlib is out of date?

I'm not horribly sure but I can't guarantee I'll be able to fix it in a timely manner, so if someone would like to investigate, I'd appreciate it.


Terence J. Grant 09/17/2006 00:04

More problems with tarlib

I've done some testing since last night…

  • tar files appear to be okay as long as you don't add directories
  • gnu tar doesn't appear to be able to verify the corrupted tar files
  • files with more than 100 characters in their path don't get added (uh-oh)

Terence J. Grant 09/17/2006 12:29

Andreas Wagner's tarlib version

A little better, but still has the same problems:

Andreas Wagner's Version

You'll need to make a “tmp” directory in your data directory and chmod it 777 to test it.

Terence J. Grant 07/10/2008 03:34

Initial release jitters

Hi all, I've gone ahead and put a list of all the known issues below; each of which is solvable, but currently still outstanding. Feel free to help me complete these early– it'll result in a faster release and more time spent on other projects. — Terence J. Grant 07/29/2006 05:44

More files to backup?

If you're aware of any important files I'm missing in the backup process, please list it below as file paths, thanks. — Terence J. Grant 07/29/2006 05:28

  • conf/mime.conf

Hello, I would appreciate if your tool could also backup conf/mime.conf. Some plugins like freemind need to have changes in mime.conf.

Thank you.


Displaying page as multi-part

Anyone have an idea on how to display the page as each individual section completes? I believe I'm doing everything right in this regard, but obviously the sever still wishes to wait until the page is completely loaded. So any help on this would be appreciated. — Terence J. Grant 07/29/2006 05:28

Tar and GZip/BZip commands

For the archiving commands ('tar') things might be a little more complex. The plugin manager includes two PHP classes, tarlib and zip.lib, I only use them for extraction in the plugin manager but a quick look makes me think they can handle archive creation and compression.

Ok, I'll look into this as well. — Terence J. Grant 08/20/2006 20:42

The harder stuff

My other ideas are:
* option to send the backup as part of its creation, i.e., the web browser will pop up its download window there and then and the admin can save the backup immediately.
Yeah, I agree… I believe this should be doable via a document.location.href JavaScript… or it could be delivered directly via the right combination of multipart-mixed headers, but frankly I don't know how to do the latter.— Terence J. Grant 08/20/2006 20:42
Its quite straight forward. The easiest way is to simply do a server side redirect to the backup file once its been created. Its also possible to send the data inline as an attachment. Both methods are described under header(). — Chris Smith 2006/08/21 19:44

Security issues

if a current backup exists, add option to only download that backup. For this, it might be necessary to be able to determine what file types are included in the backup.
Hmmm, I think keeping the current backup around (or accessible to anyone but superuser) would be a security risk… password hashes, pages with permissions, etc could all be compromised. — Terence J. Grant 08/20/2006 21:08
I wasn't thinking of it being generally available. Perhaps the installer could create a protected “backup” namespace in the media tree. Or perhaps it is a bad idea. — Chris Smith 2006/08/21 19:44
I'm prepared to help out with these changes if you don't mind.
Anything you'd like to do, feel free. I'll try to improve some things when I get a chance as well. — Terence J. Grant 08/20/2006 20:42
:!: It's necessary to set an appropriate access rights for the namespace wiki:backup, to prevent unacceptable data leaks. For example no access for @ALL. While the plugin installer doesn't do it by itself, it's better to change access rights immediatly after the first use. — Alexander Sorkin 02/04/2016 18:49
In reply to some of your other points above:
* `date "+%W"` included in the file name will add a week number. Do man date to see the other format codes. e.g.
'tar -rf backup-`date "+%W"`.tar '.$conf['olddir']

You will probably need to escape the backticks or change the quote marks from double to single to ensure PHP passes them to the shell

I was thinking of using the PHP date function originally, since myself I do backups fairly irregularly. (Sometimes I'll do twice in a day if i've had some significant changes.) The only concern I had was regarding replacing slashes in the date with dashes or something — Terence J. Grant 08/20/2006 20:42
date will work too. Try something like,

Chris Smith 2006/08/21 19:44
take a look at Andi's searchindex plugin. It uses continuous page updating to show its progress.

Okay, I'll take a look at that. — Terence J. Grant 08/20/2006 20:42
The plugin manager stores information about any plugin it installs, including the source URL. Update, simply attempts to retrieve and reinstall the plugin again from the same URL. At this time there is no intelligence behind it, i.e., it doesn't know if the plugin has been updated or even if the URL is still live.
Cheers — Chris Smith 2006/08/20 23:57


Thank you for your backup tool! Any plans to make automatically make daily/weekly backups or the option to send the backup to a certain mail address?
I personally don't have any plans myself for this– feel free to add options and send them to me (see svn for some tips.) Automated backups could be done with what's called a cron job, but most people don't have access to this.

As for mailing; I wouldn't know how to begin, though I suspect this might be easier. Again, contributions (within reason) are welcome.

Terence J. Grant 08/22/2007 17:08

I've been using this tool for a long time and just used it to migrate from an old server to a new one. Worked like a charm! Thank you for creating this helpful extension.
If a person were to automate backups via cron, how would one create a backup using a shell command?

Aaron Smith 02/06/2018 12:39

No such file

I have downloaded this plugin and all went okay, but when I process the backup I should find a back-up file in the root (“The backup file is generated and put in the root of your media directory”).
But there is no such file. What can be wrong? —FJH Langendam 08/20/2008
The file should be created in the “root of your media directory,” so this does not mean your “file system root,” this means the top level media directory.

In other words, it should be creating a file in your “data/media” directory. Is this not happening? — Terence J. Grant 08/20/2008 23:08

Another Question

Dear Terence,
I've tried it again and although DokuWiki shows the name of the bu-file (DokuWiki-backup-20080821-220132.tar.bz2) it's not in the dir (httpdocs/doku/data/media). — FJH Langendam 08/21/2008

There's a link generated on the BackupTool page, I'd suggest using that to get the file.

I'd also suggest using the media manager to delete the file.

Hope that helps,

Terence J. Grant 12/20/2008 17:03

compression type configurable

Hi Terence and thanks for your updates of this plugin.

I've just launched a new wiki at some site the PHP of which announces availability of bz2 but fails on generating anything bz2-y (also old revisions cannot be generated with bz2, e.g.), so I had to hack the code to force gzip compression. Would you consider adding the compression-type to the configurable options? (So I don't have to hack again when there's an update of the plugin.) — Andreas Wagner 11/25/2008

Hi Andreas, yes, I'll add the option as time permits. — Terence J. Grant 12/20/2008 16:56

Backup in recursion

I suspect that when the option 'media files' is selected, backup-tool tries to backup the previous backups. Here is my quick solution.

if (!bt_exec("tar ". (($i != 0) ? "-rf " : "-cf ") .$tarfilename." ". "--exclude dw-backup-* " . _getRelativePath($item))) 

Question about Tool

- Can this tool be used to migrate data from one instance of DokuWiki to another instance running on some other host?

- Does this tool work for Windows?
- (also side note: anyone know why my H2 is not being properly rendered by DokuWiki? Is the a maximum size to a page? Is there some syntax error somewhere above me?)

Peter Thung 12/16/2008
Hi Peter,
- Yes, it should be able to. There is some manual configuration that will need to be done to restore, but it's very minimal.
- It will work on Windows if you do one of two things– you'll have to decide which is easier to configure, though):
* Install tar and gzip (or tar, gzip, and bz2) via Cygwin for Windows and make it available to the server. (Or use a similar method to make tar, gzip2
* Install Pear for your PHP installation.
- Usually these are syntax errors (mismatched ”=====“ or ”**“ signs for instance), but these are questions you should ask on the DokuWiki forum.

Best of luck,

Terence J. Grant 12/20/2008 16:56
- First thanks your the response.
- When you say there are some manual configuration that will need to be done to restore, but it's very minimal, may I ask what they are, or how or where I could find them? I was able to install the backup tool and run it. I apparently already had Cygwin installed and the tool seems to work as I saw the archive created. I looked into it and saw that it appears to just backup a few directories. Would the general procedure be to shutdown Apache, delete the physical directories then manually untar/unzip the archive to replace the directories you deleted?
- In regards to installing targ and gzip for windows and making it available to the server, if I do have Cygwin installed on my windows box, is it just a matter of making those executables included on the windows Path environment variable, or is there another way? I guess the Windows path thing was enough.

Peter Thung 01/22/2009

What is the procedure to restore from the backup archive?

The following assumes that your Wiki is completely gone - you have nothing left then one backup-archive and the credentials of the Admin-User.

  1. Start the installation of the latest version of doku-wiki as if you would start with a new wiki
  2. Run install.php as described in the installation-procedure of doku-wiki - you have to set the Admin-user (I used the same name and password as the one I used in the backed wiki; I do not know yet, if this is a requirement)
  3. The directories of conf, data and lib will be empty
  4. Untar your backup and copy the three directories (conf, data and lib) to your wikis destination-dir

That's all.

Respect datadir for saving

Hi, in admin.php line 225, where the file gets saved, the plugin does not respect the setting of savedir to find the media directory. I changed the path to: “$conf['savedir'].'/media/'” and now it works. I suppose this is the intended behaviour. If not, trying to save in the wrong place can give permission problems as well as saving in the wrong place.

thanks for this plugin… greets, naja

Download is broken?

I get an “Access Denied” message in an XML file when requesting :( — Marcus Gnaß 10/20/2009

Download still broken

Same here, the link is not working. All the best, heinz

Download filename changed?

I also had problems finding it. Note name difference above good link: from backup backuptool

Thanks for the plug-in, 8-) =)

Dave B

Still problems finding backup file...

I get no errors or warnings until I try to click on the link where it says file not found. I also do not find it using FTP…(hosted on

Mikael 11/09/2009

Also problems finding backup file

I have earlier asked for the solution of not finding the backup file. When I use the generated link, the anser is a HTTP 404-page as the link is:

Offcourse the data/media-dir has rights (777).

I hope to hear from you.
FJH, 08-05-2010

Backup False failure

Hmmm…newest backup stable version (really should display the actual version number on some page). on VMWare → Linux 2.6.9-42.ELsmp

Says that it is failing, but is actually creating the TAR…just seems to not zip it? Is there some “use zip here” parameter? — Michael Quinn 2010/07/07 20:06

Files from Mac OX included in the plugin

I install the plugin from the Plugin Manager and I found estrange files inside the plugin directory. I think it may be from some Mac OS system because I see that before when someone use my pendrive in that OS.

The list of files is: ._admin.php ._.DS_Store .DS_Store ._lang ._pref_code.php

A new version

It seems this plugin hasn't been maintained for a while, and some issues have built up. In particular I the old version didn't respect $conf['savedir'] or DOKU_CONF being located anywhere other than the default locations. I've put up a forked version ( ). I also added a feature for putting the backups in a folder other than media root, so you can use ACL to control access to old backups. Also, a feature for viewing and easily deleting old backup files. I'm going to add a link to the top of the page, and hopefully get a pull request going. — Mark 2011/03/07 07:16

While it's true I'm not keeping this project up-to-date, I'd suggest pushing changes to the original repo rather than forking it. I'm getting emails from users about multiple repos containing the same code. Push changes to me and I'll approve them. Thanks in advance. — tatewaketatewake

2013/10/06 05:34

newest version does not work

First: props to you for picking up this plugin and even expanding it! Unfortunately, it does not seem to work properly, it always goes to a nearly empty page saying “The backup tool is working, please wait…”. This lasts forever (ok, for more than 15 minutes, where the old version was ready after 15 seconds) and the backup is not created. I left the preferences at their default values. Is it maybe necessary to create the namespace wiki:backup? — CantelloCantello

2011/03/15 17:35

  • Thanks for telling me about the bug – pretty weird that it just processes and doesn't finish (with error or success). Which backup method were you using for this, and how big/how many files are in your wiki – does it work quicky if you just back up Pages, for example? I've just been testing it on my wiki which doesn't have PEAR (so I can't test that) and only about 7MB size so far. As for the wiki:backup namespace, it ought to be created automatically. — Mark 2011/03/19 05:53
plugin/backup.txt · Last modified: 2018-05-26 23:35 by Klap-in