Information Systems:Exploring transactional backups for our IBM i (Bart)

From uniWIKI
Jump to navigation Jump to search

Overview

It is well understood that the value of our current backup strategy (which consists of nightly full system saves to tape) is severely undermined by the fact that all system/user activity after the backup (i.e. throughout the entire next day) is vulnerable to complete loss during a system outage. On the other hand, all exploration of potential High-availability/Disaster Recovery (HA/DR) solutions to date have centered around a second, fully operational IBM i, which, gauging merely by the inaction from past endeavors, indicates that such a solution is outside of the company's interests (primarily because of cost). Thus the goal of this endeavor is to develop a "customized" solution based on third-party software that avoids running a fully-replicated and fully-operational second machine as a requirement, yet still achieves a lower recovery point objective (RPO) and recovery time objective (RTO) than our current strategy.

Considerations

It is worthy to first note the assumptions of this exploration:

  • High-availability i.e. having a second machine ready to fail over to and serve users when the primary system is down, is of less interest to the company because a) the cost required of owning and licensing a second machine and b) the reality that any disaster impairing the system beyond immediate serviceability/repair is likely to equally affect company operation on other fronts (i.e. the case of a natural disaster affecting building infrastructure (warehouse inventory), network connectivity to the outside world, logistics (shipping routes) etc.). In other words, business continuity planning that accounts for the IBM i but not other parts of the business (i.e. ability to fulfill orders) does not make sense.
  • Because of the first point, backup technologies and concepts involving hardware mirroring to a second machine will be ignored i.e. PowerHA, FlashCopy, LUN-level switching etc. The focus will be on logical replication of data.
  • Bandwidth constraints limit any strategies that involve a full system backup over the network every night. Such solutions (i.e. Amazon S3/Glacier for x86) do not seem to be prevalent for the IBM i architecture anyhow. Nevertheless, the focus is on sending incremental data to a remote backup target.
  • Full system saves to tape and offsite storage is still a viable solution and will be treated as the null hypothesis (accepted by default and built upon unless an entire solution alternative is encountered that can replace it at more value provided to the company). Needless to say, the goal is not to replace our current tape-based backup strategy entirely, but rather to augment or revise it.

Remote journaling

Remote journaling is a core technology in all high-availability solutions for IBM i that fit under the theme of logical replication'. Remote journaling is a simple concept - it's a system feature (i.e. IBM Remote Journaling) that allows you to copy data writes to a remote target. The specifics of the configuration and differences in setup is where third-party HA solutions vary (thereby giving rise to the many different software products in the HA space), but the core technology, invariably, is remote journaling.

The basic function of journaling can be described as such:

  1. Journaling is enabled on an object (let's use the G/L file as an example).
  2. A journal receiver and a journal are created (i.e. the endpoint/target and the channel for writing data).
  3. Now, writes to the G/L file (which before would be directly to the physical file), are captured as journal entries to the journal receiver.
  4. Journal entries would accumulate during the day (as users interact with ASW and data is written).
  5. At some point, the journal needs to be committed back to the physical file, i.e. the journal entries become records in the G/L file.
  6. Journal is reset at that point, and the G/L is up-to-date.
To summarize: Base file (physical file/system object) + Journal entries = CURRENT DATA

Given the basic summary of function above, it makes sense that the journal is on a separate system (although if not for HA/DR use, local journaling has other benefits/use cases).

Retrieved from "https://owl.unipharm.com/mediawiki/index.php?title=Information_Systems:Exploring_transactional_backups_for_our_IBM_i_(Bart)&oldid=8278"