1. TRIM use cases | |
Documentation on how to use each TRIM command resides on the TRIM page. This page is to list current and future scenarios with general steps and some tips, and example use cases. Note: For all automated (unattended) operations, there should be a warning email upon failure (disk full or SSH failure) |
1.1. Create or take over a Tiki instance | |
|
1.2. Backup and restore | |
1.2.1. Backups | |
|
1.2.2. Automated backups | |
|
1.2.3. Restoring | |
|
1.3. Automated security checks | |
|
1.4. Updates and upgrades | ||||||
|
1.4.1. Update | |
|
1.4.2. Upgrade | |
|
1.4.3. Automated updates | |
Tip Makes sense to also set up automated backups
|
1.5. Cloning | |
Tip The difference with a backup: A backup provides you with an archive (.tar.bz2) of your whole instance, whereas a clone is a live usable instance.
|
1.5.1. Manual cloning | |
Use cases
|
1.5.2. Automated cloning | |
Same steps as above. Then, put on a cron job Use cases
|
1.6. Test update or upgrade | |
|
1.6.1. Manual | |
Use cases
|
1.6.2. Automated | |
Same steps as above. Then, put on a cron job Use case
|
2. Future use cases | |
|
2.1. Re-install and apply a profile | |
2.1.1. Manual | |
|
2.1.2. Automated | |
Same as above, on a daily or weekly cron job Use cases:
|
2.2. Dev-testing-acceptance-prod workflow | |
|
2.3. Show server | |
|
2.4. Delayed mirroring | |
Same daily operation as "Automated cloning" but with a lag (ex: one day, one week and one month). Suggested domain names include yesterday.example.org, aweekago.example.org and amonthago.example.org Use cases:
|
2.5. Compare Tiki instances | |
make compare should show a diff of all files in and outside the web directory, and a diff of database |