Restoring database backup results in [SPARKSEE: 28] I/O error

50 views
Skip to first unread message

Mateusz A

unread,
Nov 18, 2015, 1:43:48 PM11/18/15
to Sparksee
Hi,

I've been making automated backups (basically calling Graph.backup method), and it worked fine for several days. But now, I cannot get Sparksee to restore the database from the backed up file (while it has worked previously). I should note that the database loads without any errors (i.e. Sparksee.open does not throw any exception), and the backups are successful. Yet the resulting backup files cannot be restored.

When calling Sparksee.restore method I get an Error "[SPARKSEE: 28] I/O error". Could you give me any hint what could be wrong?

In my app I'm using Java bindings, but to extract the error message I've written a small c++ app, because the JVM was crashing with not obvious error message.

c3po.ac

unread,
Nov 19, 2015, 2:57:40 AM11/19/15
to Sparksee
Hi,

Could you tell us which Sparksee version are you using?
And the operating system may be useful too.

Does the "sparksee.log" contain any other SEVERE messages prior to this one?
Have you enabled the recovery system in Sparksee config?

We would recommend to make a copy of the database file while the database is closed.

Thanks.


El dimecres, 18 novembre de 2015 19:43:48 UTC+1, Mateusz A va escriure:

Mateusz A

unread,
Nov 19, 2015, 4:24:49 AM11/19/15
to Sparksee
I'm using 5.2.0 (from maven) on Ubuntu 14.04.
Between the time of the last valid backup and the first invalid backup, there are no messages in the "sparksee.log" file (except for the "GraphPool '...' is being saved to..." and "GraphPool '...' backup finished"). Also, during that time, the database has not been restarted. And in the log there are no SEVERE messages whatsoever.

Are you talking about making a database copy, by copying the database files? Just to make it clear, I was talking about making a backup programatically, e.g.

Database* db = sparksee->Open(L"my.gdb", L"db_name");
Session *sess = db->NewSession();
Graph *g = sess->GetGraph();
g->Backup(L"my.gdb.bak");

Then calling "Database* db = sparksee->Restore(L"my.gdb", L"my.gdb.bak");" fails.

I will try to dump the database contents using Graph.dumpData, and maybe I'll find something.

c3po.ac

unread,
Nov 19, 2015, 5:26:49 AM11/19/15
to Sparksee
Hi,

Thanks for the explanation so we know we are on the same track, what you're doing is correct. Our file copy suggestion was to have a copy of the database to be safe in case the backup file is really invalid.

Do you still have the last valid backup file?

You are saying that the database has not been restarted, so we can assume it hasn't crashed?
Have you enabled the recovery functionality using the SparsityConfig methods or the config file ?

If it has not been restarted, are you trying to restore it with a different name? or in a different application? Is the database in the same directory?

Thanks.

El dijous, 19 novembre de 2015 10:24:49 UTC+1, Mateusz A va escriure:

Mateusz A

unread,
Nov 19, 2015, 6:09:24 AM11/19/15
to Sparksee
I will probably make direct file copies for the time being, as you suggested.

I still have the last valid backup, and the first invalid backup files. I think we can assume the db didn't crash. Recovery option was enabled via SparkseeConfig. Here's a snapshot of my sparksee.log file:

2015-09-17 10:34:03.889|SPARKSEE[INFO] ** START ** 2015-09-17 10:34:03.889 Software version: 5.2.0
2015-09-17 10:34:03.889|SPARKSEE[INFO] Decoded license: Software version [5] Objects limit [1000000] Sessions limit [1] Identifier [20001] Expiration date [7/2016] High-Availability [off]
2015-09-17 10:34:03.896|RM[INFO] RECOVERY ENABLED
2015-09-17 10:34:03.959|RM[INFO] RECOVERY DISABLED
2015-09-17 10:34:03.959|RM[INFO] REDO PHASE: 0 OPERATIONS
2015-09-17 10:34:03.959|RM[INFO] RECOVERY ENABLED
2015-09-17 10:34:03.961|SPARKSEE[INFO] GraphPool 'lokaligo' has been opened at /gdb/data/lokaligo.gdb
2015-09-17 13:09:00.790|GraphPool[INFO] GraphPool 'lokaligo' is being saved to '/mnt/gdb1-backup/files/lkg-2015_09_17-13_09_00.gdb' backup file...
2015-09-17 13:09:04.733|GraphPool[INFO] GraphPool 'lokaligo' backup finished.
(several more backups...)
2015-09-27 01:09:01.136|GraphPool[INFO] GraphPool 'lokaligo' is being saved to '/mnt/gdb1-backup/files/lkg-2015_09_27-01_09_01.gdb' backup file...
2015-09-27 01:09:02.337|GraphPool[INFO] GraphPool 'lokaligo' backup finished.
2015-09-27 13:09:01.770|GraphPool[INFO] GraphPool 'lokaligo' is being saved to '/mnt/gdb1-backup/files/lkg-2015_09_27-13_09_01.gdb' backup file...
2015-09-27 13:09:02.976|GraphPool[INFO] GraphPool 'lokaligo' backup finished.
2015-09-28 01:09:00.895|GraphPool[INFO] GraphPool 'lokaligo' is being saved to '/mnt/gdb1-backup/files/lkg-2015_09_28-01_09_00.gdb' backup file...
2015-09-28 01:09:02.399|GraphPool[INFO] GraphPool 'lokaligo' backup finished.
2015-09-28 13:09:00.611|GraphPool[INFO] GraphPool 'lokaligo' is being saved to '/mnt/gdb1-backup/files/lkg-2015_09_28-13_09_00.gdb' backup file...
2015-09-28 13:09:02.106|GraphPool[INFO] GraphPool 'lokaligo' backup finished.
2015-09-28 14:23:34.275|GraphPool[INFO] Closed /gdb/data/lokaligo.gdb
2015-09-28 14:23:34.290|GraphPool[WARNING] Removed /gdb/data/lokaligo.gdb.tmp
2015-09-28 14:23:34.305|SPARKSEE[INFO] ** SHUTDOWN ** 2015-09-28 14:23:34.304
2015-09-28 14:23:38.789|SPARKSEE[INFO] ** START ** 2015-09-28 14:23:38.788 Software version: 5.2.0
2015-09-28 14:23:38.789|SPARKSEE[INFO] Decoded license: Software version [5] Objects limit [1000000] Sessions limit [1] Identifier [20001] Expiration date [7/2016] High-Availability [off]
2015-09-28 14:23:38.801|RM[INFO] RECOVERY ENABLED
2015-09-28 14:23:38.947|RM[INFO] RECOVERY DISABLED
2015-09-28 14:23:38.947|RM[INFO] REDO PHASE: 0 OPERATIONS
2015-09-28 14:23:38.947|RM[INFO] RECOVERY ENABLED
2015-09-28 14:23:38.959|SPARKSEE[INFO] GraphPool 'lokaligo' has been opened at /gdb/data/lokaligo.gdb
2015-09-29 01:09:00.466|GraphPool[INFO] GraphPool 'lokaligo' is being saved to '/mnt/gdb1-backup/files/lkg-2015_09_29-01_09_00.gdb' backup file...
2015-09-29 01:09:03.639|GraphPool[INFO] GraphPool 'lokaligo' backup finished.
(...)

So the database has been running since Sep 17th, until Sep 28th, when I restarted the app. The last valid backup (which I can restore, either using my original Java app, or a simple C++ app I made) is on 2015-09-27 01:09, and the first invalid is on 2015-09-27 13:09.

If it has not been restarted, are you trying to restore it with a different name? or in a different application? Is the database in the same directory? 

I'm restoring it using the same database file name. Tried it in my original Java app, and simple C++ app (just to see if the Java code was valid). DB is in the same directory when restoring, although in production it has a separate directory.
 

Thanks,
Mateusz

c3po.ac

unread,
Nov 19, 2015, 10:09:15 AM11/19/15
to Sparksee
Hi,

While you make direct copies of the database file, the database must be closed to be sure that all the information is written.

How big are these files (the database and the backup) ?
Could you send the invalid backup file to dam...@sparsity-technologies.com ?

Do you remember if the schema was modified between the last successful backup and the bad one? Or only nodes, edges and attribute values were updated ?

Thanks.

El dijous, 19 novembre de 2015 12:09:24 UTC+1, Mateusz A va escriure:

Mateusz A

unread,
Nov 19, 2015, 11:00:15 AM11/19/15
to Sparksee
I don't know how big the database was when the backups became invalid, but the backup itself was 1.3 MB (I've sent it to the email you mentioned). Currently, the main database is ~37MB, the ".log" file is ~11MB, and the resulting backups are ~6.4MB.

I will try to export using "Graph.export" method, but including all the node and edge properties (instead of just the OIDs, which is the default — and which worked fine).

Thanks,
Mateusz

Mateusz A

unread,
Nov 19, 2015, 11:25:01 AM11/19/15
to Sparksee
Also, between the last valid backup and the first invalid one, there were no schema migrations (they could be performed only when the database starts, but not in the middle of operation).

c3po.ac

unread,
Nov 23, 2015, 6:37:56 AM11/23/15
to Sparksee
Hi,

There was indeed a bug in an optimization process used to reduce the size of the backup that caused the restore parser to fail.
The good news is that the bug didn't corrupt the data because it only added extra unnecessary data that the restore parser couldn't handle. Thus, fortunately no data in your backup file has been lost.

If you need your faulty backup, Damaris can send you the fixed backup file. Your current sparksee release should be able to restore it.

She will also send you a patched Sparksee release in short.

Thanks.


El dijous, 19 novembre de 2015 17:25:01 UTC+1, Mateusz A va escriure:

Mateusz A

unread,
Nov 23, 2015, 6:44:23 AM11/23/15
to Sparksee
Hi,
That's good to hear, thank you!
In that case, I probably won't need the fixed faulty backup I've sent to you.

Cheers,
Mateusz
Reply all
Reply to author
Forward
0 new messages