As to your specific question of whether there is a method to move your wiki from one server to another, I can answer with an emphatic, "well, yes and no."
The wikiadmin tool can be used to export and import wikis, and generally works as long as the database your wiki is built upon is currently stable.
Also, depending upon the version of Server.app you are running, the options may vary slightly - though simply typing the command, 'wikiadmin' without the quotes should give you a usage listing to assist with the particulars of your version. If you are using Server 5, you will find a more fully featured export capability than has existed in prior versions. It even gives you 3 options for export format:
- Legacy (the only format which can also be imported into the Server.app wiki)
- NSDictionary (not importable to Server.app)
- JSON (not importable to Server.app, but it is human readable and does provide the option of moving your wiki to other platforms which support the JSON format)
If this is your preferred route, you should refer to ALTERNATIVE 2: WIKIADMIN PROCEDURE, below.
There is also another method which is entirely undocumented by Apple, to my knowledge, but which I have uncovered in my research into Postgres in attempting to correct the many problems I have encountered with the system.
The primary benefits of this second method are that a) it is simple b) it is faster, as Apple is already generating the required file output for you, and c) has obviously designed their system to rely upon this method, at least in more recent iterations of Server.app.
In fact, if you are using Time Machine to back up your server, it is the only method available to restore the system from that Time Machine backup.
So, this procedure can be used both to restore and to move your wiki to another server running a compatible version of Server.app.
If this is your preferred route, you should refer to ALTERNATIVE 1: POSTGRES RESTORE PROCEDURE, below.
Let me qualify all of this advice by stating that I am not an expert in either database administration or the wiki server. If you do not understand what is going on with each of these steps, I suggest you refrain from trying them as I cannot account for the particulars of anyone's setup outside of my own. ALWAYS MAKE A FULL BACKUP OF YOUR SERVER BEFORE ATTEMPTING ANY OF THESE STEPS. ALSO, USE OF 'SUDO' COMMAND CAN BE DANGEROUS AND POTENTIALLY DESTABILIZE YOUR ENTIRE SYSTEM. PROCEED WITH CAUTION.
If you have corrections or additions to make, I would hope you add them to this discussion in order to help the many people who struggle to maintain their servers.
Also, these steps assume that you are running version 5.0.4 or equivalent of the Server.app and may require modification to work in other versions.
ALTERNATIVE 1: POSTGRES RESTORE PROCEDURE
Background: Apple has integrated what is known as pg_basebackup for the wiki database. pg_basebackup is a Postgres backup feature which generates a fully restorable copy of your wiki database, excepting the file data imported to the wiki (e.g. pdf's, xlsx's, docx's, etc.). References to the files remain intact and function properly as long as the file data is maintained in its properly structured state. It is actually a very powerful backup feature which even permits Point In Time Recovery (PITR) among other things should you decide to delve deeper. Postgres documentation for the feature can be found here: 24.3. Continuous Archiving and Point-in-Time Recovery (PITR)
The output generated by pg_basebackup will appear here: /Library/Server/Wiki/Database.xpg/backup/base_backup/base_complete.tar.gz
It is a zipped tarball which can only be managed with tar commands (e.g. tar -tzvf to list contents, tar -xzvf to extract contents). It can also only be accessed by privileged users, so commands must be prefaced by the 'sudo' command)
You do not need to do anything to this file, as long as the file has been generated cleanly from a stable database. In fact, this is the only database cluster file you will find in your Time Machine backups. If you look, you will see that the backup skips over the actual database cluster, altogether - and for good reason. Any copy Time Machine might make of the cluster will be prone to corruption and data integrity issues as they would be snapshots taken across different times while the database is manipulating those files and could easily catch them in an unstable state before transactions have been fully completed. The pg_basebackup procedure prevents this from happening and Time Machine is smart enough to know which one to keep.
The rest of your wiki data will be found here: /Library/Server/Wiki/FileData
If you have both the base_complete.tar.gz file and the FileData folder from the same point in time, you have all of your wiki data.
- Move Server.app to the Trash (/Applications/Server.app) but do not empty the trash (you will need to provide an Administrator password, then wait for notification that "Server.app removal had been detected" and the app SHOULD automatically shut itself down. Give it a moment to complete)
- If you have the full contents of the /Library/Server/Wiki folder, you can replace the existing contents of the /Library/Server/Wiki folder with the one you are trying to restore. If you only have the FileData and base_complete.tar.gz data, you can try replacing only the FileData and Database.xpg folders and leaving in place the Config and other folders from a clean installation of Server.app - your mileage may vary with this approach.
- You must then ensure these files have proper ownership and read/write access. Though perhaps overzealous, I set the permissions wide open in order to guarantee there are no errors generated by lack of access. The Server.app should set the ownership and permissions as it prefers upon setup. The two commands would be: 'sudo chmod -R 777 /Library/Server/Wiki' and 'sudo chown -R _teamsserver:_teamsserver /Library/Server/Wiki' without the quotes.
- Make sure there are no stale sockets. 'sudo rm /Library/Server/Wiki/PostgresSockets/.xpg*' without the quotes.
- "Put back" the Server.app that is held in Trash.
- Run Server.app and follow setup procedure
- Monitor logs for a clean setup. It will take time as it is untarring the tar ball to create the restored database cluster and may be updating the database as well, depending on the versions involved.
If you are moving your wiki to a new server or to a rebuilt server, make sure you have already run Server.app and configured the system to a consistent state with the old server before proceeding with the procedure outlined above. Open Directory, DNS, etc. are not carried over with this procedure and may be required for the proper access and function of the wiki.
-----------------------
ALTERNATIVE 2: WIKIADMIN PROCEDURE
Simply type 'wikiadmin' without the quotes into your Terminal window to be presented with a list of options associated with your version of wikiadmin. Running the tool will require privileged access and requires use of the 'sudo' command to operate.
The following will assume that you are using Server.app 5.0.4 or a compatible version.
You can export a single wiki or the entire database if you choose. To get a listing of all exportable wikis, use the command: 'sudo wikiadmin export -l' without quotes. If you wish to only export a subset of all wikis, you will need to grab one of short name, long name, tiny ID, or GUID to properly identify the wikis.
- Export all wikis in importable format with this command: 'sudo wikiadmin export -all -path /var/tmp/all_wiki_export' without quotes or alternately, only specified wikis with: 'sudo wikiadmin export -name [wiki_name, wiki_name, ...] -path /var/tmp/one_wiki_export' You can substitute an alternate path, though it can become problematic and prevent a successful export - so I would stick with putting it in /var/tmp/[folder name]. Tip: The folder should not already exist and will be created by the export procedure. The output generated by this command will use the default format (Legacy) which has the significant feature of being importable - essential if you wish to place your wiki onto another server or onto your rebuilt server. Other formats (NSDictionary, JSON) should only be used when importing is not necessary.
- The output can be moved and copied in its native state, or rolled into a compressed tarball according to your preference. 'tar -czvf' is the root command for this, but you should consult the tar man page if you wish to use it - command: 'man tar' without quotes. Place in /var/tmp/ on the destination machine.
- On the destination server, all setup should be complete before proceeding with the import. Again, Open Directory, DNS, etc. will not come across in this procedure. This is a wiki only process.
- Untar the tarball if necessary 'tar -xzvf', otherwise proceed to next step.
- Import all wikis with command: 'sudo wikiadmin import -all -path /var/tmp/all_wiki_export' without quotes
Depending upon the size of your wiki, this is likely to be a time consuming process. As a point of reference, my database export with < 2GB database and ~25GB of file data, the import process alone was around 10 hours. Get some coffee 🙂
Hopefully, this information is helpful. I know I would have found this helpful about 6 weeks ago when our wiki crashed so hard as to be apparently irredeemable. I have found almost zero documentation from Apple, and lots of stabs in the dark from commenters in support forums. Very little in the way of answers when things no longer run properly.
Should your database be in an unstable condition, there may be some steps that an experienced database guru might be able to perform in order to stabilize without too much loss of data - but I wouldn't rely on it.
BE AWARE: Making regular backups is essential to preventing data loss, but may not be sufficient by itself. As I discovered only recently, your wiki may be operating with only occasional hiccups and yet already be in an "unstable" condition. The only way to learn this, as far as I know, is to also attempt regular exports - as the export process itself will fail when it has become sufficiently compromised. So strange behavior may ensue, even when falling back to earlier dates which appeared sufficiently stable (we have all come to expect a certain amount of inconsistency in the Server.app performance as it falls far short of Apple's typical standards).
Restoring from backups which you assumed to be stable based on user experience at the time they were made may instead turn out to be sufficiently compromised as to be near to impossible to bring back online. The backups themselves may fail to reconstitute properly upon setup. I intend to post my experience with this shortly to see if anyone can assist in overcoming this problem - as it can result in a significant or even total loss of data, as even your oldest backups may have integrity issues of which you were completely unaware. Even when they can be "reconstituted" successfully through this restore process, they may remain "unexportable" (all attempts to export fail) and therefore potentially impossible to rebuild through the export-import process and thus remain trapped in a downward spiral of deterioration which ends in complete collapse.