Btw, do you think it's worth it to open a feature ticket because of the filenames?
The index (last number in front of the db suffix) should IMO always have the same number of digits - 01 (or 00001) instead of 1 makes sorting easier...
I'd agree that padding the index to two digits would be a good thing, but I think that's a much smaller issue than what's going on in the first place. I'm not sure it's a huge problem--the files are expired at 30, so this isn't going to take more than 10 MB or so of space, but it seems odd that (apparently) multiple backups of the config database are stored at the same time. For example, right now, I have 17 copies from 3 Jan. Of those, 14 are from between 17:16:05 and 17:16:08. At that time, the system was rebooting after installing an update. The first on that date is from 07:22, the second is from 14:19. At 14:19, I installed a new USB stick to mirror the boot device, but I don't see anything in the system logs for 7:22. The last is 17:17:02, just under a minute after the bulk of them.
Unfortunately, trying to export these to XML repeatably crashes SQLiteStudio 3.0.1 on my Mac, but I can export them to SQL. Diff between two of the 17:16 files shows no differences other than the header line ("File generated with SQLiteStudio v3.0.1 on Mon Jan 5 09:07:11 2015", of course the date/time will be different). Diff between the 07:22 file and the 14:19 file shows two lines dealing with the storage_disk table (understandable). Diff between one of the 17:16 files and the 17:17 file shows a bunch of differences (1421 lines per wc -l).
So, a change to configuration was made on 3 Jan at 14:19, and a copy of the database was saved. The system was rebooted at 17:16, and a bunch of apparently-identical copies were saved. The database schema was updated for the update at 17:17, and a copy was saved (this is just speculating, but it seems consistent with the facts that (1) an update was installed, and (2) there were lots of diffs from the previous backup). This still leaves the 07:22 file unaccounted for, but I think it's making some progress in explaining what's happening.
It's looking like 9.3 has implemented a mechanism to save copies of the config database whenever a change is made, which is a good thing. The only apparent bug is that rebooting the system floods the backup directory with a bunch of copies.