I believe so, if the data is corrupted then the backup process will encounter
the corruption when it tries to read out the corrupted entries in order to
output them and should fail accordingly
The same should hold true of trying to use tbddump on a database, essentially
the Fuseki backup is
Ok, well compacting by using dump is not a problem.
Another question related to backup: when backing up disk image and all
jena data files as is, possible data corruption is backed up too without
warning. But if exporting data with Fuseki's built-in backup and saving
that, does Fuseki give
Inside a TDB2 directory, you'll see "Data-0001". That's the first
database. TDB2 has a "compact" operation which would create "Data-0002"
etc and after that Data-0001 is not used and never touched. Delete or
archive as you choose.
It's simple at the moment - a copy of the database so much
Yes, there is some truth in that.
TDB1 uses a dictionary that maps node IDs to node labels (so that, e.g. a
literal that is used as an object doesn't need to be in-line recorded in the
indexes, which could quickly bloat the indexes). That dictionary isn't "garbage
collected", so part of what
Just managed to load using tdbloader2, it even reads the gz file
directly. Noticed that new database size on disk is quite a bit smaller:
payload size: 2.8Gt
old size on disk: 21Gt
new size on disk: 3Gt
So it seems that its good to do cleanup of the db every now and then
using the backup?
That dataset is just an NQuads file. You can stick it into Fuseki as you would
do with any other NQuads file. You can certainly use tdbloader2, or you can
script individual graph loads using GSP. tdbloader2 will produce an optimal set
of indexes.
ajs6f
> On Jun 14, 2018, at 7:55 AM, Mikael
Hi,
made backup using Fuseki HTTP Administration Protocol:
ds_2018-06-14_14-43-32.nq.gz
How do I restore it in Linux? Empty existing data and use tdbloader2?
How exactly?
Thank you
