Backup_Slave/Backup_Master *base* state data structure

Logs parsing for Backup Slave and Backup Master are virtually the same, so the logic has been moved to shared parent -

But the data is stored separately in state->{'Backup_Slave'} and state->{'Backup_Master'} depending on where it came from.

In all examples below, I write state->{'Backup*'}, and it relates to both places in state.

Within state->{'Backup*'} data is kept using following structure:

state->{'Backup*'}->[ n ] = { DATA }


  • n is just a number, irrelevant. The only important fact is that higher n means that backup started later.

  • DATA - data about archiving this segment

DATA is arrayref which contains:

  • [0] - epoch of when omnipitr-backup was called

  • [1] - process number for omnipitr-backup-* program (pid)

  • [2] - epoch when backup was fully done.