Hi everyone,
I've deleted accidentally the metabase.db.mv.db and metabase.db.trace.db. The metabase is still working ( didn't stopped the running process ), it's using MariaDB as database but I'm so scared to the cards, query's, etc will be gone when I stop the running process.
There's any kind of way to regenerate those files ? The last backup of those files is 3 months ago ... I've been looking around the metabase configuration panel but i don't see any option like that.
Any help will be appreciated.
@Asaodie That depends on your OS. It's not really related to Metabase. It's like deleting an Excel file really doesn't have anything to do with Excel, but your OS and if you have backups.
Search the internet for ways to recover deleted files on your operating system.
But go to Metabase > Admin > Troubleshooting > look at "Diagnostic Info", if it says you are using MariaDB as the application-database, then the H2 file doesn't matter.
Hi flamber, thax for answering,
OS is debian ( Linux ) and I guess the recover from an rm is not possible ( that's why I'm looking for a file "regeneration" way ).
That's what the diagnostic info says ( I'm using a mysql database but the metabase is using H2 ?¿ )
{
"browser-info": {
"language": "es-ES",
"platform": "Linux x86_64",
"userAgent": "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.64 Safari/537.36",
"vendor": "Google Inc."
},
"system-info": {
"file.encoding": "UTF-8",
"java.runtime.name": "OpenJDK Runtime Environment",
"java.runtime.version": "11.0.14+9-post-Debian-1deb10u1",
"java.vendor": "Debian",
"java.vendor.url": "https://tracker.debian.org/openjdk-11",
"java.version": "11.0.14",
"java.vm.name": "OpenJDK 64-Bit Server VM",
"java.vm.version": "11.0.14+9-post-Debian-1deb10u1",
"os.name": "Linux",
"os.version": "4.19.0-5-amd64",
"user.language": "en",
"user.timezone": "Europe/Madrid"
},
"metabase-info": {
"databases": [
"mysql"
],
"hosting-env": "unknown",
"application-database": "h2",
"application-database-details": {
"database": {
"name": "H2",
"version": "1.4.197 (2018-03-18)"
},
"jdbc-driver": {
"name": "H2 JDBC Driver",
"version": "1.4.197 (2018-03-18)"
}
},
"run-mode": "prod",
"version": {
"date": "2022-02-28",
"tag": "v0.42.2",
"branch": "release-x.42.x",
"hash": "d6ff494"
},
"settings": {
"report-timezone": "Europe/Madrid"
}
}
}
@Asaodie Several things to try before shutting down Metabase (and crying):
https://superuser.com/questions/283102/how-to-recover-deleted-file-if-it-is-still-opened-by-some-process
https://unix.stackexchange.com/questions/80270/unix-linux-undelete-recover-deleted-files
Ignore the trace file. It's only a log, doesn't contain any data. Focus on metabase.db.mv.db
After you maybe have recovered the H2 file, then do the following:
- Make sure you have a proper backup in the future. Search the internet for articles about backup. It has absolutely nothing to do with Metabase.
- Migrate away from H2 as the Metabase application database: https://www.metabase.com/docs/latest/operations-guide/migrating-from-h2.html
Hi flamber,
I've found a solution ( after trying everything and getting my stress to unexpected levels >.< ). I'm going to post it here for someone who has this problem on the future.
As I said, the instance of metabase was running so I've searched the process with lsof|grep '/home/x'
Found several metabase proc, just pic some one of those:
java 14774 15143 streaming x 28uW REG 9,2 1411768320 5772123 /home/x/metabase.db.mv.db (deleted)
Just need those numbers 14774 and 28 ( only the number, the uW it's not required ). After that just simply cp the file with:
cp /proc/14774/fd/28 metabase.db.mv.db
And it works, epic terror moment, as you suggested I'll migrate that H2 hellish thing to mysql.
1 Like
@Asaodie Excellent with your little writeup.
Even though H2 should not be used in production, I'm sure you could have run drop database <somedb> on MySQL and have been in even worse situation.
Think the key takeaway is: Make sure you have backups. Make sure they work, otherwise you don't have backups. Search the internet for "backup 3-2-1" for guiding principals of backup.