Thanks. I’m just tying to have as many “fail safe” options as possible. I have all of my personal and research files in DT. I also religiously do two external backups on two different drives each week stored in two different locations. Thanks again.
I have more (2 external USB drives, NAS, created and maintained by two backup software packages, and Backblaze).
1 Like
Yes. Go to the folder in Finder where your DT databases are stored. Inside that folder you should find one or more .dtBase2 files. Those are package files where each DT database you’ve created are stored. Right click on the .dtBase2 file of interest and select “Show Package Contents.” This will reveal the folders into which DT has sorted the database’s contents.
But note: it’s NOT whatever folder hierarchy you may have sorted the files into. Your document files should be in a folder called Files.noindex. From there, DT has sorted your documents into folders by type (PDF, eml, xls, etc.) and from there into subfolders with alphanumeric names starting with 1-9, then with a-z.
I’ve rarely had to reach into the database package to retrieve anything, but a simple Finder search has turned up whatever document I’ve needed to find.
That is awesome and adds a great deal of confidence in using DT should the worst happen. Thanks!
For those reading this thread … while the files are all accessible via the operating system (Finder, other file apps, even “terminal”) inside the DEVONthink databases (macOS Packages), it is essential to not “mess” with any of the files without risk to corrupting the DEVENthink database as any of those changes not done by DEVONthink. All access should be via the DEVONthink app.
3 Likes
But I could safely copy and save elsewhere if ever needed, correct?
Yes, of course. But–to do this I think the best way to copy and save elsewhere is to take “Database Archive” which makes a zip file of the entire database. Of course files “indexed” into the database with “pointers” to files in other places are not included in that Archive. All this and more discussed and documented in the “DEVONthink Manual” freely available by DEVONtechnologies’ web site.
Great advice, thanks. I just made a recurring reminder to create an archive every 6 months. Much appreciated!
I make automated archives of all datatabases once a week, keeping the three most recent. Those zip archives, and the un-zipped databases (macOS packages) also backed up with the normal and regular system backups.
1 Like
I never had issues either, for over 10 years and then I did. Burned badly, won’t go back.
Keep in mind an Archive will only copy bad files not test them.
All that happens is you can identify the lost files using the File/Check File Integrity funciton. As far as I can tell they never really fixed the problem just can identify it faster now. I just did a quick look at the official forum and I can’t find any indication that they actually solved the bug.
2 Likes
FWIW I had backups monthly going back over ayear and the files were bad on all of them. I never found out until I actually needed to LOOK at the files. Then I discovered it.
That is exactly why I do test restores of these zip archives and all other backups approx once a quarter. cannot recall when a backup tested flawed. knock on wood.
And, even though I delete all but the last three zips, since these are included in the full system backups, I can go back a loooong time (only limited by disk allocation for these backups on the NAS).
your mileage obviously different. something wrong.
Well it is not that expensive you know, not really and it goes on for years before you have to upgrade. I have to say that I have used it for years. As others have implied, start using it and your uses and its usefulness will increase in ways you didn’t anticipate.
I do things with it that I wouldn’t be doing at all were it not for the app. I have a place where I put screenshots of academic papers and site pages for example, I use a smart rule to title them and can re-find them easily and in a curiously relevant way hard to explain and that wouldn’t work if I littered my desktop with such.
I would say I am still learning and developing usage of it after over five years. Really take the plunge.
1 Like
And you (and all) should not be rooting around in a database’s internals unless instructed to do so. You risk database corruption messing about in there.
4 Likes
et al:
We have discussed this all many times before (including on our forums), but you should be routinely checking the health of your databases.
Especially if you’re a heavy user of DEVONthink, we suggest a weekly or bi-weekly check with File > Verify & Repair on each database, just to make sure they’re doing well. You obviously can do it more often, if you’d like.
3 Likes
Understood. It was an abandoned database on a laptop that was no longer in active use and on which DTP was no longer installed. The point is that the documents could still be retrieved, even without DTP.
2 Likes
Count me among the minority who say “no.”
I set it up a while back to go all in with DT. On paper, I look like the ideal user. Instead, the result was frustration and continuous insults thrown my way by the DT “support community.”
I’m only one perspective and experience, but I thought I’d add it to the mix so you can see what happens when you criticize DT.
4 Likes
Unless you test you’re entire backup, all files, the chances of identifying an error will vary depending on how many items you have in your DT database and whether you happened to pick one that was corrupted to try to recover. In my case I had many thousands of individual items.The issue is that they LOOKED fine. Valid file names, showed up in my DT folders as I expected.
My DT databases all passed the verify and repair database and optimize database procetures that DT recommends. I was doing the verify and repair weekly, the optimize monthly and the rebuild quarterly all per DT support suggestions. But it STILL failed me. That procedure is NOT enough to actually catch the bug in time to recover lost files.
That was my experience too. For months I was told that the fault was mine that I was clearly not seeing what I knew I was seeing and I got tired of shouting at the wall only to be ignored. It was only AFTER another frustrated user developed a procedure to locate the corrupted files and others started reporting the issue that DT regular support actually considered that we might be seeing a real problem. And the response was just a way to check for it not a real fix and it’s NOT just do a regular Verify and Repair.
3 Likes
You could setup an intelligent group, that shows over all databases all documents with a file size of 0kb.
So you could have a look onto it, and if it indicates any file in there, you could take the approbate actions.