This depends on your definition of consistent. By default asbackup will use the ‘scan’ method, which will slowly crawl through all the records in the namespace. As it finds a record, it will be recorded into the backup file. If using a ‘last-update-time’ option it will also check against the metadata stored in primary index. However, this backup is not a snapshot/consistent backup in many ways… Since it is a kind of ‘top-down’ approach and there is no forward log recovery concept, or quiesce, the records may change holistically as you do the backup… Ex… if record#1 is at the top and backup is done, you continue on your backup - but then as your application makes changes it will not be backed up again. So if your application changes record#300000 and also record#1 after the record#1 was backed up - it could be said that these records are now ‘out of sync’. It’s like taking a panoramic picture where there is a cut off arm somewhere, if I had to make an analogy.
It is a difficult problem to solve within the Aerospike world indeed 
Your endtime of the backup can be recorded in your script… but you should assume that you may need to re-backup things since that time as I explained the above concept… ex… if you start an incremental backup of “since 6/3/2018” starting at 9:00 am today and finish it at 10:00 am today, if you wanted to ensure you back up every change since your last backup next time you would want to punch in since 9:00… Does that make sense?
date;asbackup;date