First off, let’s tackle getting your data back—your best bet depends on whether you have backups in place:

• If you have regular backups (via asbackup):
  This is the fastest way to restore. Use the asrestore command to push the backup back into your test namespace. Example command:

  asrestore --namespace test --directory /path/to/your/backup/dir
  

  Just make sure your Aerospike cluster is in a stable state before running the restore.
• If no backups exist:
  Since your namespace uses the memory storage engine (no disk persistence), once data is cleared from memory, it’s gone for good unless you can catch it before node restarts. If any nodes haven’t been rebooted since the data loss, you could try checking for residual in-memory records with aql, but this is a long shot.

Let’s dig into why this might have happened, even with your TTL overrides:

1. Verify actual TTL values on records
   Even if you ran a UDF to set TTL to -1, it’s possible some records were missed. Use aql to check the TTL of any remaining records (or check historical logs if you have them):

   SELECT ttl FROM test.your_set WHERE PK='sample-key'
   

   Remember: Aerospike treats -1 as "never expire", but if your UDF didn’t run against every record, those un-updated ones would hit the 30-day default TTL and expire.
2. Scan Aerospike logs for clues
   Check your main log file (usually /var/log/aerospike/aerospike.log) for these keywords:
   • expire or evict: Look for entries indicating mass expiration/eviction, like:

     Jun 15 09:45:00 INFO [evictor] (ticker): evicting 45000 records from namespace test
     This would confirm if records were removed due to TTL or memory pressure.

   • namespace config: Check if anyone modified the test namespace config—like changing default-ttl or adjusting memory limits—around the time data disappeared.
   • cluster events: Look for node restarts, cluster rebalances, or node failures. While these usually don’t wipe data, misconfigurations during cluster changes could cause unexpected data loss.
3. Validate your UDF execution
   Check logs for the UDF scan job to confirm it updated all records. You should see entries like:

   Jun 10 14:20:00 INFO [scan] (scan): scan completed: namespace test, set user_data, records scanned 60000, records updated 60000
   If the "records updated" count doesn’t match your total dataset size, some records were never updated to TTL -1 and expired later.

4. Check memory pressure and eviction rules
   Your namespace has a memory-size of 4G. If your dataset grew beyond this limit, Aerospike would trigger LRU eviction to free up space. While eviction doesn’t usually wipe all data at once, it could look like a sudden drop if memory was completely exhausted. Use asadm to check namespace metrics:

   asadm -e "show namespaces"
   

   Look at the memory_used value for test—if it’s close to or over 4G, eviction is a likely culprit.
5. Rule out accidental human error
   Even if you didn’t run delete commands, it’s worth checking if someone else did. Look for DELETE statements in aql logs, or check if a UDF with delete logic was run. If you have Aerospike auditing enabled, review audit logs for any write/delete operations on the test namespace.

内容的提问来源于stack exchange，提问作者Awadesh