rsnapshot: Auto Version Controlled Backup for Unix/Linux/Mac/BSD…

Red Had Enterprise Linux (RHEL) 6. I missed the ease of configuration and all the free tools that people smarter than me have created.

Systems that can take advantage of Rsnapshot

Systems that can take advantage of Rsnapshot

I would like to do a fast post on rsnapshot. I have seen ssh and rsnapshot scheduled in cron to automate backups of OSX to a Linux server. Since we didn’t want the wireless to slow down we only used the physical MAC address of the MAC. What makes rsnapshot so great is that it will wok on so many systems that are out there (Ubuntu, Debian GNU/Linux, Red Hat Linux, Fedora Linux, SuSE Linux, Gentoo Linux, Slackware Linux, FreeBSD, OpenBSD, NetBSD, Solaris, Mac OS X, and even IRIX) .

For now I’m using it for personal automated backups to my external hard drive. There are plenty of other advanced options and examples on the Internet. I just wanted to get out a fast an easy example.

  1. First – find and install rsnapshot. for Red Hat this was
    $ sudo yum install rsnapshot
    (rsynch is a dependancy that should already be installed).
  2. After install if you do not have this file /etc/rsnapshot.conf. Use the command:
    $ sudo cp /etc/rsnapshot.conf.default /etc/rsnapshot.conf
  3. Edit rsnapshot.conf – The defaults I changed from the default configuration file are below. These options allow me to back up everything in /etc/ and /home/. Backups kept will be twice a day, 7 days a week, 4 weeks, 12 months and 5 years (change this as you see fit).  Most important is that switch to make sure that the mount point will not be created and wrote to locally if the disk is not attached.
    1. WHERE TO PLACE BACKUPS
      # All snapshots will be stored under this root directory.
      #
      snapshot_root   /media/myexternal/rsnapshot/
    2. DO NOT CREATE IF DISK IS NOT CREATED
      # If no_create_root is enabled, rsnapshot will not automatically create the
      # snapshot_root directory. This is particularly useful if you are backing
      # up to removable media, such as a FireWire or USB drive.
      #
      no_create_root 1
    3. INTERVALS (make sure this is tabbed – do NOT use spaces)
      #########################################
      #           BACKUP INTERVALS            #
      # Must be unique and in ascending order #
      # i.e. hourly, daily, weekly, etc.      #
      #########################################
      interval        hourly  12
      interval        daily   7
      interval        weekly  4
      interval        monthly 12
      interval        yearly  5
  4. Time to configure cron. Most people will tell you to create your jobs using $ crontab e
    I prefer to use the root crontab using $ sudo vim /etc/crontab shown below:

    0 */12 * * * root /usr/bin/rsnapshot hourly # Every 12 hours
    30 23 * * * toot /usr/bin/rsnapshot daily   # Daily at 11:30PM
    20 2 * * 0 root /usr/bin/rsnapshot weekly   # Sunday at 2:20AM
    10 5 1 * * root /usr/bin/rsnapshot monthly  # First day of the month at 5:10AM
    01 8 1 1 * root /usr/bin/rsnapshot yearly   # January 1st at 8:01AM
  5. Test It – Following these steps you should have the basic setup needed to run rsnapshot on your personal computer to an external hard drive or usb. Just one last thing to do. Make sure that your hard drive is plugged in and  run:
    $ sudo rsnapshot -V hourly
    rsnapshot should give you plenty of verbose information as it creates your first hourly backup inside the location you specified. If there is a issue with the lock file, remove the lock file and try again.

Still stuck?

There are many other helpful documents out there  start with the rsnapshot how to:
http://www.rsnapshot.org/howto/1.2/rsnapshot-HOWTO.en.html#installation

If you want to learn how to do remote backup and use OSX? try this article:
http://blog.philippmetzler.com/?p=138

As I said in the beginning of this article, this was a fastpost and not meant to cove everything about rsnapshot. It took longer to write this article than it did to set up rsnapshot.
Good Luck – Adam M. Erickson

 

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

Risk Management Planning

Risk Management Plan

Risk Management Planning

Risk management typically follows four stages in an iterative process. These are identification, assessment, planning and monitoring. They should be followed at project start-up and then monitored in response to change, completion of project stages. One of the main reasons why risk-management activities fail to deliver as well as they should is because they get treated as a one-time exercise. Once the full heat of the project battle is underway, plans and contingencies get left to gather dust on the shelf. This is a sad waste; the initial assessment will have helped identify where the project is most at risk and will have helped focus attention on how to mitigate these risks (or accept them). However, the lack of monitoring allows new risks to emerge, or old ones to grow more serious, without anyone actually noticing. It then comes as a surprise that the roof has fallen in on the project.

indentify risk

The above picture demonstrates the dimensions of where risk comes into play when dealing with project risk management that must be dealt with.

Identification of Risk

Identification is the first step. Ideally, it involves asking anyone and everyone (within reason) to identify any risks they consider might apply to the project, a checklist may be involved like the one on the next page.

Question/comment Yes/no
Has a complete risk identification/assessment/planning exercise been conducted?
Is there an ‘owner’ for this process?
If not, have all the areas of risk been considered? As below:

Commercial?

Technical?

People?

Politics?

Process?

Change?

For all the risks identified, is there a realistic assessment of impact and probability?
Have these risks been ranked (prioritized) according to impact and probability

Identifying and classifying risk.

probability of occurrence

Risk Analysis

Once risk has been identified they can then be rated according to severity and probability. Normally, this is done on the basis of low, medium or high for both categories as seen in the above diagram.

We try to base on ranking the risks according to combined impact and probability. The first filter employed would be to eliminate all the very low risks. These need only be considered if their ranking changes in the future, it is not a good thing to to simply file and forget risks. The ranking process can then be applied to give increasingly higher profiles to high-impact/probability risks. During this assessment process, we could associate/review ranking numbers with the impact on budget and time. This can then be used to keep a track of how risks evolve with time as a result of project progress, risk reduction and contingency plans, plus events in the outside world.

 Risk Response

Following on logically, once the nature of the risk has been fully assessed, the next step is to develop a plan for dealing with each risk. These typically include: ignore it, take mitigating action to reduce the chance of it happening or minimize the impact, and have a contingency plan in case it actually comes to pass.

These are the four main solutions to risk for when they can potentially occur:

1. Avoidance

Includes not performing an activity that could carry risk. An example would be not buying a property or business in order to not take on the liability that comes with it. Another would be not flying in order to not take the risk that the airplane were to be hijacked. Avoidance may seem the answer to all risks, but avoiding risks also means losing out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a business to avoid the risk of loss also avoids the possibility of earning profits.

2. Reduction

Involves methods that reduce the severity of the loss or the likelihood of the loss from occurring. Examples include sprinklers designed to put out a fire to reduce the risk of loss by fire. This method may cause a greater loss by water damage and therefore may not be suitable. Halon fire suppression systems may mitigate that risk, but the cost may be prohibitive as a strategy.

3.   Retention

Involves accepting the loss when it occurs. Risk retention is a viable strategy for small risks where the cost of insuring against the risk would be greater over time than the total losses sustained. All risks that are not avoided or transferred are retained by default. This includes risks that are so large or catastrophic that they either cannot be insured against or the premiums would be infeasible. This may also be acceptable if the chance of a very large loss is small or if the cost to insure for greater coverage amounts is so great it would hinder the goals of the organization too much.

4. Transfer

Means causing another party to accept the risk, typically by contract or by hedging. Insurance is one type of risk transfer that uses contracts. Other times it may involve contract language that transfers a risk to another party without the payment of an insurance premium. Liability among construction or other contractors is very often transferred this way. On the other hand, taking offsetting positions in derivatives is typically how firms use hedging to financially manage risk.

 The risk identification, assessment and planning stages need to be re-evaluated when things change. This can either be done by having regularly timed reviews (with the overhead that you might have reviews when you don’t need them). Alternatively, risk reviews can be implemented whenever there is a request for a change, however trivial, or by setting criteria that determine the extent of the reviews according to the extent of the change.

Risk Monitoring and Control

The monitoring process will be to systematically tracks and evaluate the effectiveness of risk handling actions against established metrics. Monitoring results may also provide a basis for developing additional risk handling options and approaches, or updating existing risk handling approaches, and reanalyzing known risks. In some cases monitoring results may also be used to identify new risks and revise some aspects of risk planning. The key to the risk monitoring process is to establish a cost, performance, and schedule management indicator system over the program that the program manager and other key personnel use to evaluate the status of the program. The indicator system should be designed to provide early warning of potential problems to allow management actions. Risk monitoring is not a problem-solving technique, but rather, a proactive technique to obtain objective information on the progress to date in reducing risks to acceptable levels.

“Best practices” acknowledges that all of the traps have not been identified for each risk issue. The traps are intended to be suggestive, and other potential issues should be examined as they arise. It is also important to recognize that sources and types of risk evolve over time. Risks may take a long time to mature into problems. Attention must be properly focused to examine risks and lessons learned.

Lessons learned should be documented so that future project managers can learn from past mistakes.

From past companies, and education, I have developed  risk management plans. That included risk management planning, identification of risk, risk analysis, risk response (including avoidance reduction transfer and retention), and risk monitoring and control.

As I find time, I will post more information.

WORKS CITED

Andersen, Erling S.; Grude, Kristoffer V.; Haug, Tor.; Katagiri, Mike.; Turner, J. Rodney
Goal Directed Project Management: Effective Techniques and Strategies
3Rd Ed. / Edited By Mike Katagiri, Rodney Turner. : London ; Sterling, VA : Kogan Page, 2004.

Ben-David and T. Raz An Integrated Approach for Risk Response Development in Project Planning; The Journal of the Operational Research Society, Vol. 52, No. 1 (Jan., 2001), pp. 14-25

Kerzner, Harold; Project Management: A Systems Approach to Planning, Scheduling, and Controlling : New York John Wiley & Sons, Inc. (US), 2001.

Nickson, David.; Siddons, Suzy;Project Disasters & How to Survive Them;: London ; Sterling, VA : Kogan Page, 2005.

Smith, Nigel J.; Managing Risk in Construction Projects : Oxford ; Malden, Mass. Blackwell Science, 1999.

[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]