Month: March 2013

Recovery Time Objective vs. Recovery Point Objective

RTO & RPO are two non-functional requirements that affect the business continuity management. While RTO has much broader impact, both of these factors should be determined objectively based on the need and cost factor in mind.

picture-for-rto-rpo2I am currently reviewing non-functional requirements for a project I am working on and the topic of Recovery Time Objective (RTO) and Recovery Point Objective (RPO) came up. While both RTO and RPO talks about business continuity, there are subtle differences.
 
RTO determines how quickly a system can recover in case of a disaster. The shorter the time span, the more investment is necessary to recover from an incident. For instance, if the RTO is 60 minutes, backup systems should be ready for a seamless switch over. System configurations should be transparent & decoupled to enable this – meaning, no hard-coding of servers in configuration files etc. Systems should also be replicated at memory and database level to achieve this. Compare this with an RTO of 1 day which provides enough time for switch over manually and the investment is very low. Ofcourse, for today’s production systems an RTO of one day is unacceptable. The point is, if your client is bent on reducing the RTO, they should also be ready to loosen up their purse strings.
 
RPO on the other hand indicates how much work can you affort to lose. For instance, if your system writes to a data store, is it tolerable to lose one hour of work, or four hours of work? The number of hours here is the RPO and helps formulate a strategy for backup. If your RPO is four hours, then you need to perform backup atleast every four hours, but if your RPO is one hour then your backup strategy should match. Ofcourse, this will increase the infrastructure cost.
 
Obviously, RTO has a much broader boundary as it impacts business continuity management, while RPO is focused on backup frequency. Regardless, these number should be determined objectively based on the need and cost factor.

Renaming a file on Mac

Renaming a file on a Mac is not so obvious; plus an Automator script to rename files.

mac-rename

One would think that renaming a file on Mac must be easy given the user-friendliness of Mac OS. Turns out, it is not so obvious.

To rename a file in Finder, you click on the icon preceding the file name once and then click on the file name again. This will highlight the file minus the extension. Now you can type the new name to rename.

Having said that, I was able to create a Automator script that will pop-up a dialog to rename either part of the file (base or extension) by right-clicking and selecting the Services option.

Following is the snapshot of the Automator script.

Automator Script

 

What is MongoDB

Main features of MongoDB

Mongodb

MongoDB is an open source, document-based database management system. Designed for the data and scalability requirements of modern internet applications, MongoDB features dynamic queries and secondary indexes; fast atomic updates and complex aggregations; and support for replication with automatic failover and sharding for scaling horizontally.

Document Databases

Explores the difference between the leading document databases, CouchDB and MongoDB

mongodb.pngExcerpt from Mongo DB in Action – “Few databases identify themselves as document databases. The other well-known document database apart from MongoDB is Apache’s CouchDB.

CouchDB’s document model is similar, although data is stored in plain text as JSON, whereas MongoDB uses the BSON binary format.

Like MongoDB, CouchDB supports secondary indexes; the difference is that the indexes in CouchDB are defined by writing map-reduce functions, which is more involved than the declarative syntax used by MySQL and MongoDB.

They also scale differently. CouchDB doesn’t partition data across machines; rather, each CouchDB node is a complete replica of every other.”