How to delete Backups located inside DT databases?

As the free space on my Mac’s system drive has recently started to decline rapidly, I discovered that some DT databases have backup folders in them called something like “Backup 2021-04-23 11-17-09”.
Those folders are frequently several GBs in size.

I have not found anything mentioned about this in the DT docs or the forum.
Is there a function in DT3 to remove those backups? If not, can I just delete the folders from the Finder?

Thanks!

Wait; I don’t think that is correct. I’m AFK, I’ll respond in more detail later. @StefanKah, you don’t mention zip - and you’re not seeing zips, but folders, right?

1 Like

Oh dear. Good catch if not zip.

I’ve deleted my bad advice. I found inside the DEVONthink database “package” (somewhere I never look out of not really something for end-users to mess with!) and see the internal backups discussed on page 19.

Good spot all.

1 Like

Read page 19 of the current manual, ‘A Word About Backups’. You can safely delete the internal backups, but DEVONthink will continue to create them in the future.

1 Like

Yes, those folders I mentioned are inside the .dtBase2 files

See @Greg_Jones response.

How many Backup folders are you seeing? There should only be two.

Also, I would not think this would be the first place to start cleaning up a machine.
Have you looked at your Downloads folder? It is often a place full of old and no longer needed files.

Yes, “internal backups” seems to be the correct term for this.

This “feature” strikes me as not thought through (and documented) properly;

Nowhere in the manual does it mention that each internal backup will potentially double the disk space required. E.g. for one of my databases with ~ 3 GB worth of index files, there are two internal backups, each taking up an additional 2.9 GBs.
IMO, there should be a way for the user to actively enable/disable a feature that can cost such a lot of disc space.

Also, the manual says

DEVONthink backs up its database index every week, either immediately after opening the database (if the backup is overdue) or during the day when appropriate.

How many Backup versions does it create? One? Two? Any unlimited number, until the system runs out of disc space?

It seems that this feature wasn’t working correctly in previous versions of DT3 (at least on my Mac), because I see this creation of internal backups only since i upgraded to 3.7.2 4 days ago.

How many Backup versions does it create? One? Two? Any unlimited number, until the system runs out of disc space?

As I said: two. They are created weekly and only two are preserved.

IMO, there should be a way for the user to actively enable/disable a feature that can cost such a lot of disc space.

We used to allow people to specify the number of backups. However, due to people putting unreasonable settings, e.g., 24 backups / hourly, DEVONthink 3 now controls the process and rotates two backups.

I would suggest it wouldn’t be wise to disable this option as it is used in troubleshooting situations, e.g., a failed rebuild, and there would be no similar mechanism. Only a full restoration of a database could be used, assuming backups are current and existent (an assumption we do not make).

For a database containing only indexed files, it stands to reason that an internal backup of the database will be of the same size as the database itself, as that database effectively only contains metadata and not the items themselves.

To my knowledge, there will be two backups - and as I write that, Jim has just responded and confirmed that to be the case. As for deactivating this safety mechanism - whilst I understand what you are saying, I don’t unreservedly agree with you and there is precedent on both sides of the argument: I can, for example, deactivate some safety related driver assist systems in my car, but I can’t turn off the side-impact airbags. DEVONthink have repeatedly pointed out that more choice means more of a learning curve for new users, and I can understand that this was a choice which was dropped (I may stand corrected, but I think there was a choice in DT2; and in an addendum to his original post, Jim has just confirmed that, too).