If using the "Incremented Number [1-999]" backup method, once the incremental suffix reaches 999 it will not rollover to 001. Instead it switches, without notice, to creating "YYMMDD_HHMMSS" backups. This is with V3.59 64-bit on Win 10.
I have one psafe3 db that reached the 999 limit (i.e. there were three backups in the directory being used for backup). Let's call them: xxxx_997.ibak, xxxx_998.ibak, xxxx_999.ibak. The next intermediate backup ended up with the YYMMDD naming convention, as well as dozens of subsequent ones before I caught it.
I manually changed the setting back to "Incremented Number [1-999]", but it continued to create YYMMDD backups, and the setting again changed itself to YYMMDD. After futzing around with it, I manually renamed the 997, 998, and 999 numerical backups to: xxxx_001.ibak, xxxx_002.ibak, xxxx_003.ibak. After confirming that the backup setting was on "Incremented Number", the backups and the "Max 3" limitation started working as expected again, with the next backup being xxxx_004.ibak and the xxxx_001.ibak being automatically deleted.
I've been using the incremental backup method for many years. I only keep the last 3 saves, and it has previously rolled over to 001 once reaching 999. This works fine for me as the databases are in the cloud, mirrored locally, and redundantly/regularly backed up by various means. The YYMMDD method is nice, but has no method that I can find to restrict the number of backups being created. So it must be manually managed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Seems like preventing overwrite on earlier backups once the limit is reached is a feature. Maybe what you can do is make a feature request to allow overwriting previous backups when the limit is reached if using Incremented Number backup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If using the "Incremented Number [1-999]" backup method, once the incremental suffix reaches 999 it will not rollover to 001. Instead it switches, without notice, to creating "YYMMDD_HHMMSS" backups. This is with V3.59 64-bit on Win 10.
I have one psafe3 db that reached the 999 limit (i.e. there were three backups in the directory being used for backup). Let's call them: xxxx_997.ibak, xxxx_998.ibak, xxxx_999.ibak. The next intermediate backup ended up with the YYMMDD naming convention, as well as dozens of subsequent ones before I caught it.
I manually changed the setting back to "Incremented Number [1-999]", but it continued to create YYMMDD backups, and the setting again changed itself to YYMMDD. After futzing around with it, I manually renamed the 997, 998, and 999 numerical backups to: xxxx_001.ibak, xxxx_002.ibak, xxxx_003.ibak. After confirming that the backup setting was on "Incremented Number", the backups and the "Max 3" limitation started working as expected again, with the next backup being xxxx_004.ibak and the xxxx_001.ibak being automatically deleted.
I've been using the incremental backup method for many years. I only keep the last 3 saves, and it has previously rolled over to 001 once reaching 999. This works fine for me as the databases are in the cloud, mirrored locally, and redundantly/regularly backed up by various means. The YYMMDD method is nice, but has no method that I can find to restrict the number of backups being created. So it must be manually managed.
Seems like preventing overwrite on earlier backups once the limit is reached is a feature. Maybe what you can do is make a feature request to allow overwriting previous backups when the limit is reached if using Incremented Number backup.
This has happened to me a few times (I have 1290 entries in the safe currently...) and I find it very annoying. It should roll back to 001.
It is not about protecting earlier backups as the backups xxx_001.ibak, xxx_002.ibak etc. are long gone when you are in the 900s.