Tiny Core Linux – Part 6 – Back to the drawing board!

Things are starting to behave strangely with the /usr/local/mysql/data folder refusing to back up, 2 cron processes being kicked off at start-up and no SSH service!!! Data corruption in the mydata.gz file? USB key physical failure?

Time to get back to the drawing board… Easier, simpler and more backed-up than ever! Hopefully…

My leads so far:

Web Server Strategy
– OS: TinyCore Linux – run off frugal install on USB
– Required software: Dropbear, Apache with PHP support, MYSQL

– WordPress install

– WordPress Backup to Dropbox plugin AND simple-restore tool
+Modify .htaccess to allow access to wp-cron.php, see http://wordpress.org/support/topic/why-won%E2%80%99t-my-backup-start

Run filetool.sh -b ONCE (once set-up is complete with empty wordpress install complete with the 2 plugins and restore tool) and leave it as a manual process.

For smoother integration (and a chance to automatically restore after shutdown, so far the restore options are manual only), check http://wordpress.org/plugins/backupwordpress/faq/, this would require to mount //popcorn at boot, restore backup from //popcorn at boot and back up to //popcorn on a schedule…

TEST IT! In theory, this should eliminate any requirement to run filetool.sh -b on a schedule (no cron, no massive backup file, no data corruption). Just backup the wordpress install to dropbox using wordpress built-in plugins and restore at boot time.

To extend WordPress

For overall reference

Once I get the chance to actually do those, I’ll post a follow-up.


Tiny Core Linux – Part 5 – SQL corruption

So despite my regular back-ups, one of the regular power cuts happened exactly during the auto-update of my RSS feeds and.. corrupted the database to the point where the mysql service wouldn’t start. And with the autocopy of the filesystem every 15 minutes, all of that got backed up, rendering any recovery impossible. I ended up wiping the /usr/local/mysql/data directory and creating everything anew, losing all my data in the process.

Once I got up and running again, what to do to prevent this from happening? Extra backup! I added 2 cron jobs calling scripts, one to back-up specifically the /usr/local/mysql/data directory as a .tar under /opt/backups/ on a weekly basis, one to run a mysqldump .sql export of all the databases on a daily basis, stopping the apache service beforehand (and restarting it upon completion) to reduce the risk of data corruption.. AND rotating the .tar and .sql backups up to 7 iterations. Next time, I should (?) be able to get a clean copy of my data, minimizing any loss. We’ll see at the next power cut!

Syntax of the mysqldump command (note the lack of space between -p and the actual password value):

sudo mysqldump -u username -ppassword–lock-all-tables –all-databases

Tiny Core Linux – Part 4 – Tiny Tiny RSS AutoUpdate

So I tried to use the simple background update (third option at http://tt-rss.org/redmine/projects/tt-rss/wiki/UpdatingFeeds) but a) it triggers an authentication request from my company’s firewall every time and b) as the feeds I am looking at only keep the 20 most recent items, I do need to update pretty regularly, not only when my browser is open.
So I set up option 2, which is the periodical updating from crontab. On Tiny Core Linux, I first had to update /usr/local/lib/php.ini with the right location for the mysql.so extension, which is not the /usr/local/lib/php/extensions default but /usr/local/lib/php/extensions/no-debug-non-zts-20090626 (not actually sure why?) in order to allow the php executable to run without apache.
Then, the command to enter in the crontab to run the job every 15 mins (it doesn’t allow you running it as root) is:

*/15 * * * * su tc -c “/usr/local/bin/php /usr/local/apache2/htdocs/rss/update.php -feeds -quiet”