1) The reduced size of the full backup a month later is indeed puzzling if you did not modify the configuration of the backup (e.g., /etc/tklbam/overrides) or delete something. Cached files somewhere on your server might be responsible so make sure it's not that. I would take a careful look at the backup logs in /var/log/tklbam-backup. The log includes a list of all files backed up which you could use to compare between sessions. Another way to explore and verify your backups is to spin up an instance on EC2 for an hour and restore your backup to it. Verifying that your backups work is supposed to be one of the main advantages of TKLBAM. Once you restore the backup, I recommend you use the "ncdu" program to figure out how the disk space is used.
2) Don't worry about data retention. We will soon add a feature to the Hub that allows you to specify maximum full backups. The logic is straightforward: we already have the list of full/incremental sessions in the database and we already have a hook that runs when a backup record is updated. So every time a backup is updated we can run a little check on it. If a new full backup has just been completed, we check how many full backups there are in total and if the number exceeds the maximum, we delete the oldest backup chain. By default, the Hub's data retention for a given backup will be set to "unlimited" unless you change it. That way we don't accidentally delete any data you might need.
3) The creation date of the backup record makes sense as it tells you how far back the records go. Whether or not a specific backup is an incremental session or a full backup is a technical detail. The ultimate result should be the same - you can restore the machine state from that date. But I'd like to know more about your use case. Could you explain a bit more why you care to know what the last full backup is? What problem does this solve? How do you use that information?
Exploring backups, data retention, backup creation date
2) Don't worry about data retention. We will soon add a feature to the Hub that allows you to specify maximum full backups. The logic is straightforward: we already have the list of full/incremental sessions in the database and we already have a hook that runs when a backup record is updated. So every time a backup is updated we can run a little check on it. If a new full backup has just been completed, we check how many full backups there are in total and if the number exceeds the maximum, we delete the oldest backup chain. By default, the Hub's data retention for a given backup will be set to "unlimited" unless you change it. That way we don't accidentally delete any data you might need.
3) The creation date of the backup record makes sense as it tells you how far back the records go. Whether or not a specific backup is an incremental session or a full backup is a technical detail. The ultimate result should be the same - you can restore the machine state from that date. But I'd like to know more about your use case. Could you explain a bit more why you care to know what the last full backup is? What problem does this solve? How do you use that information?