August 2011

Alfresco has been working great for over a month now. One thing that had been nagging me was a successful backup and restore. I figured out the problem. I wanted to test on a practice machine, so not to brick the production site. That was the thorn in my side. I could create a new Alfresco setup from scratch that worked fine. I wanted to test with the real data though. I figured if I could accomplish this – then disaster recovery would be solved too (bring data and site up on a completely new machine in short order).

The premise seemed simple enough, but execution was unsuccessful. I tried all kinds of methods. I stopped Alfresco and copied the complete alf_data folder over to new machine. I thought that should work. It didn’t. Then I went through various cold and hot backup procedures, like:

backup mysql database (while Alfresco running) to an sql file
stop Alfresco
copy the data and lucene indexes (alf_data basically)
restart Alfresco on production machine and stop Alfresco on test machine
place the alf_data folder in proper place on test machine
restore the mysql database by using the sql file
restart Alfresco on test machine

The different combinations yielded different results, but mainly the indexes would be corrupted even though the database was backup up properly. I read somewhere that using mysqldump alone is not good enough because it does not actually backup up all the data properly. I used Webmin and got the 3 databases backed up automatically (alfresco, mysql, test). So that was not the problem. Stopping Alfresco and tarring the whole alfresco folder should have done it, but that didn’t even work.

The problem? The test machine was a 32-bit version and the production machine was 64-bit. At first, I thought it was because I was using Ubuntu 10.10 on test machine (production was Ubuntu 10.04). There were just too many 64-bit libraries and binaries in the 64-bit version to manually, methodically switch out on the test machine. Since I didn’t have a spare 64-bit box lying around, I built a new one. I did have a 64-bit AMD processor lying around and found a spare motherboard and 2G RAM – so I put it together to complete the new test machine. Installed the same Ubuntu 10.04 on it and got everything updated and running. Well, after this it seemed like a piece of cake. Creating a complete clone was as simple as untarring the the opt/alfresco folder and contents to the new machine, starting Alfresco and I was golden. Things have to be the same for it to be a total clone, like having the same SMTP server running on it. I didn’t have Postfix running initially, so the email portions failed. But it was sigh of relief to see the site come up without a hiccup. OK, this works flawlessly if everything is in the same ‘/opt/alfresco’ folder (like the default). But data really should be on a different partition or spindle (different hard drive).

So my next task was moving the data to a different area. This is where you supposedly should have the databases backup properly and the actual data saved (in the right order). But moving the data was actually simpler than that. Assuming you have a stable data store, all you have to do is:

stop Alfresco
copy alf_data folder with GUI or tar it (-cfv)
paste the folder to new location, or untar (-xfv)
delete contents of /opt/alfresco/tomcat/temp
rename original alf_data folder to something else
if you don’t have a huge site, delete backup lucene indexes in new alf_data location
delete lucene index folder in new alf_data location
make sure you have the ‘index.recovery.mode=AUTO’ line in global properties
change location of data ‘dir.root=/new location’ in global properties
restart Alfresco

This worked without a hitch. I restarted a second time after deleting the alfresco and tomcat logs to get a clean picture of current system and site. The site worked as it should with data in new location. Note that I did not have monkey around with mysql database to get this to work. This is because the mysql database was shut down properly and databases and actual data files were not corrupt. This method wil NOT work if there is a problem (main reason why you backup and restore). This is where the backup/restore procedures come into play. Having data in different drive or partition adds an extra step because you must rely on the mysql database to bring back the indexing properly. See this: http://wiki.alfresco.com/wiki/Backup_and_Restore

Finally had some time to tinker again. This time working on the distance sensing function of eventual autonomic robot. I turned to a good ol’ Arduino for the physical IO. I got a Nano, and this is a sweet little microprocessor. All the functions of an Uno crammed into a little DIP from factor. For testing things out it is stellar. Just plug into USB port of PC and run your IDE of choice and your off. I decided on a Seeed Studio ultrasonic rangefinder. This is pretty much the same as a Parrallax Ping sensor, or the SRF-05 rangefinders. This Seed studio unit has 1cm resolution and pretty inexpensive.

My goal is to get the forward focal point more resolution (like a telescopic lens vs. a fisheye). Ultimately I could and should use a laser rangefinder, but this approach is quick & dirty and ripe for tinkering. My thinking was that perhaps I could narrow the dispersion of the ultrasound at least on the transmitting side. I knew that because the sensors are separated by about an inch, narrowing the input or receiving side would reduce the amount of echo reception perhaps too much and give haphazard results. Ultrasonic waves travel in a more focused pattern compared to audible waves in the first place. So by creating a smaller source of waves, I believe the “beam” will be narrower. My thought was to cover up the exposed area of the transmitting speaker – they are little speakers in there (like whizzer cones in old automobile full-range speakers).

Nano-focused SONAR

Upon testing, I found that the stream of data (microsecond time) was pretty consistent with stray numbers that were off the chart determined to be the reflected ultrasound inside the chamber getting out through the hole. By filtering that out in the Arduino sketch, I could get reasonable results.

SONAR Output

Since the above output was centimeters, I think the resolution is decent enough. Before the lens mask and filtering, I had all kinds of values in a pretty wide range. My guess it was from the transducer dispersal pattern catching an object behind or to the side of what I thought was in front of the rangefinder. I will modify the code to test output in a graph to test the narrowness of the beam on real world objects. I will either grab the values and put in Excel or write some code using Processing (www.processing.org) to show the graph realtime.

Speaking of Processing – I love that software suite, platform, IDE or what ever you want to call it. It uses the same format and syntax as Arduino sketches right down to the graphic interface. So if you know “C like” sketches, using Processing will come to you quickly. I found this awesome sketch by Lucky Larry in the UK who wrote a sketch for his pan-tilt rig using a rangefinder. He wrote a graphical radar-like realtime screen output from the rangefinder and it is pretty slick. I modified it a bit for my purposes, but kudos to him for the original sketch.

Graphic SONAR output (Processing)

So that is the screen you see while Processing is running the sketch. Basically, you run your rangefinder sketch on the Arduino – make sure the serial output screen is not open. Then you run the Processing sketch which reads the serial stream. I modified the code to show “ping” reflections as dots instead of polygon areas. I also changed it sweep only 4 degrees on either side of 90 degrees. I can see a lot of potential with Processing and the Arduino family of processor boards for physical computing feedback.

Alfresco Backup & Restore

Back to Sensing