Hi,

maybe a dumb question, but I just want to know for sure. In the documentation I read that a LEVEL 1 backup contains all data that has changed since the last LEVEL 0 backup.

So this would mean that

• I make a LEVEL 0 on Sunday
• I make a LEVEL 1 on Monday evening
• I make a LEVEL 1 on Tuesday evening and if successful I delete the one from Monday

and in the Tuesday backup I have all the changed data from Monday and Tuesday.

I did the test, and I did have the changes from both Monday and Tuesday, but I just don't have enough knowledge of informix and ontape internals to be entirely confident.

Another reason I ask is that during testing, the LEVEL 1 archive from Monday was twice as large as the one on Tuesday (17Mb vs 9Mb).

Thanks and best regards,
Arjen Van Drie.

------------------------------
Arjen Van Drie
------------------------------

#Informix

Hi Arien,

I think you're correct and Tuesday's L 1 backup should do and also 'contain' Monday's changes. I guess you even could restore Monday's and Tuesday's L 1 backups, in this order... but no point in doing this.

The reason I put 'contain' in quotes is that these incremental backups don't really contain changes, but only their end results. For instance you might have created and populated a large new database before Monday's L 1 backup, then dropped this very database (and maybe recreated it with much less data) before Tuesday's L 1 backup, so Tuesday's backup would be smaller, but would contain exactly what you need for getting back to that point in time.

Point-in-time (PIT) restores also are a reason why you might want to keep Monday's backup even after you created a new one on Tuesday.  If you want to restore to a PIT between Monday's and Tuesday's backup, you'd save logical restore for all the interval between Sunday's L 0 backup and your target PIT.

HTH,
 Andreas

------------------------------
Andreas Legner
------------------------------

Thanks Andreas,

also for your remark about keeping the Monday backup after all.

I also notice that an ontape restore is actually quite fast. Is there any more documentation on ontape internals: how does the program work exactly? I only find docs on syntax and how to use it.

Best regards and thanks again,
Arjen.

------------------------------
Arjen Van Drie
------------------------------

Original Message:
Sent: Mon June 14, 2021 09:18 AM
From: Andreas Legner
Subject: A bit more clarity on LEVEL 1 backups

Hi Arien,

I think you're correct and Tuesday's L 1 backup should do and also 'contain' Monday's changes. I guess you even could restore Monday's and Tuesday's L 1 backups, in this order... but no point in doing this.

The reason I put 'contain' in quotes is that these incremental backups don't really contain changes, but only their end results. For instance you might have created and populated a large new database before Monday's L 1 backup, then dropped this very database (and maybe recreated it with much less data) before Tuesday's L 1 backup, so Tuesday's backup would be smaller, but would contain exactly what you need for getting back to that point in time.

Point-in-time (PIT) restores also are a reason why you might want to keep Monday's backup even after you created a new one on Tuesday.  If you want to restore to a PIT between Monday's and Tuesday's backup, you'd save logical restore for all the interval between Sunday's L 0 backup and your target PIT.

HTH,
 Andreas

------------------------------
Andreas Legner
------------------------------

Quite generally, as the backup side falls into two parts, the 'physical' spaces backup (a snapshot of the used parts of your chunks - as simple as that) and the 'logical logs' backups, also the restore would first perform so called physical restore which is copying back that snapshot into your chunks, followed by logical restore which applies (rolls forward) ligical logs, from log backups, up to either PIT or latest log.

If you're finding ontape fast (and your system is reasonably large), you might be surprised how even faster the onbar alternative can be.  The main differences are: ontape is a single process that does everything strictly serially and into/from a file or tape device, while onbar, working with a storage manager, can work on BAR_MAX_BACKUP/BAR_MAX_RESTORE space backup objects at a time, potentially cutting backup and restore times to a fraction of what ontape needs.
With Informix' own Primary Storage Manager "PSM", putting backups to locally (or cloud) attached storage and usually working well right out of the box, you'd have the ease of both worlds, i.e. onbar's parallelim and flexibility as well as independence from any third party storage manager and backing infrastructure.

Enough? ;-)
You could easily fill a week with Informix backup&restore.

BR,
 Andreas

------------------------------
Andreas Legner
------------------------------

Original Message:
Sent: Mon June 14, 2021 09:37 AM
From: Arjen Van Drie
Subject: A bit more clarity on LEVEL 1 backups

Thanks Andreas,

also for your remark about keeping the Monday backup after all.

I also notice that an ontape restore is actually quite fast. Is there any more documentation on ontape internals: how does the program work exactly? I only find docs on syntax and how to use it.

Best regards and thanks again,
Arjen.

------------------------------
Arjen Van Drie
------------------------------


Original Message:
Sent: Mon June 14, 2021 09:18 AM
From: Andreas Legner
Subject: A bit more clarity on LEVEL 1 backups

Hi Arien,

I think you're correct and Tuesday's L 1 backup should do and also 'contain' Monday's changes. I guess you even could restore Monday's and Tuesday's L 1 backups, in this order... but no point in doing this.

The reason I put 'contain' in quotes is that these incremental backups don't really contain changes, but only their end results. For instance you might have created and populated a large new database before Monday's L 1 backup, then dropped this very database (and maybe recreated it with much less data) before Tuesday's L 1 backup, so Tuesday's backup would be smaller, but would contain exactly what you need for getting back to that point in time.

Point-in-time (PIT) restores also are a reason why you might want to keep Monday's backup even after you created a new one on Tuesday.  If you want to restore to a PIT between Monday's and Tuesday's backup, you'd save logical restore for all the interval between Sunday's L 0 backup and your target PIT.

HTH,
 Andreas

------------------------------
Andreas Legner

Enough for now :)

I don't have a lot of time right now to dig into onbar, but we do have a couple of large databases to take some time to backup and restore. I will keep your recommendation in the back of my mind.

Best,
Arjen.

------------------------------
Arjen Van Drie
------------------------------

Original Message:
Sent: Mon June 14, 2021 11:58 AM
From: Andreas Legner
Subject: A bit more clarity on LEVEL 1 backups

Quite generally, as the backup side falls into two parts, the 'physical' spaces backup (a snapshot of the used parts of your chunks - as simple as that) and the 'logical logs' backups, also the restore would first perform so called physical restore which is copying back that snapshot into your chunks, followed by logical restore which applies (rolls forward) ligical logs, from log backups, up to either PIT or latest log.

If you're finding ontape fast (and your system is reasonably large), you might be surprised how even faster the onbar alternative can be.  The main differences are: ontape is a single process that does everything strictly serially and into/from a file or tape device, while onbar, working with a storage manager, can work on BAR_MAX_BACKUP/BAR_MAX_RESTORE space backup objects at a time, potentially cutting backup and restore times to a fraction of what ontape needs.
With Informix' own Primary Storage Manager "PSM", putting backups to locally (or cloud) attached storage and usually working well right out of the box, you'd have the ease of both worlds, i.e. onbar's parallelim and flexibility as well as independence from any third party storage manager and backing infrastructure.

Enough? ;-)
You could easily fill a week with Informix backup&restore.

BR,
 Andreas

------------------------------
Andreas Legner
------------------------------


Original Message:
Sent: Mon June 14, 2021 09:37 AM
From: Arjen Van Drie
Subject: A bit more clarity on LEVEL 1 backups

Thanks Andreas,

also for your remark about keeping the Monday backup after all.

I also notice that an ontape restore is actually quite fast. Is there any more documentation on ontape internals: how does the program work exactly? I only find docs on syntax and how to use it.

Best regards and thanks again,
Arjen.

------------------------------
Arjen Van Drie


Original Message:
Sent: Mon June 14, 2021 09:18 AM
From: Andreas Legner
Subject: A bit more clarity on LEVEL 1 backups

Hi Arien,

I think you're correct and Tuesday's L 1 backup should do and also 'contain' Monday's changes. I guess you even could restore Monday's and Tuesday's L 1 backups, in this order... but no point in doing this.

The reason I put 'contain' in quotes is that these incremental backups don't really contain changes, but only their end results. For instance you might have created and populated a large new database before Monday's L 1 backup, then dropped this very database (and maybe recreated it with much less data) before Tuesday's L 1 backup, so Tuesday's backup would be smaller, but would contain exactly what you need for getting back to that point in time.

Point-in-time (PIT) restores also are a reason why you might want to keep Monday's backup even after you created a new one on Tuesday.  If you want to restore to a PIT between Monday's and Tuesday's backup, you'd save logical restore for all the interval between Sunday's L 0 backup and your target PIT.

HTH,
 Andreas

------------------------------
Andreas Legner