datomic 2018-03-11 | Slack Archive

thosmos20:03:48

I'm attempting to restore a db from one system into another for the second time. The first restore created the db on the target system, but the second time it reports that all segments were skipped. Any ideas what I'm doing wrong? I'm using exactly the same URI on both servers.

marshall20:03:09

@thosmos you're seeing skipped segments because they are already present in the storage. Restore only copies the things that aren't there yet

thosmos20:03:16

@marshall yes I understand that, but ALL of the segments are skipped, including the newer ones that have been added to the source db since the previous backup/restore

thosmos20:03:48

in other words, when I do an incremental backup, 2 new segments were added, but when I do a restore, 0 segments were copied

marshall20:03:27

Are you restoring with a t argument?

marshall20:03:52

Can you list backups in the backup location as well?

thosmos20:03:39

wondering if it is a timezone issue. destination system reports a lower t than the backup point:

~# datomic/bin/datomic list-backups file:/root/backup-20180311
(140416)
~# ./datomic/bin/datomic restore-db file:/root/backup-20180311 $URI 140416
Copied 0 segments, skipped 0 segments.
Copied 0 segments, skipped 1578 segments.
:succeeded
{:event :restore, :db test2, :basis-t 140415, :inst #inst "2018-03-11T19:16:06.226-00:00"}

marshall20:03:23

Thats the same basis. Iirc list backups reports the next-t

marshall20:03:05

Have you queried the restored db for some of the newly added datoms?

thosmos20:03:16

yes, it's still the old state

marshall20:03:33

Have you transacted against the db in the secondary storage between original restore and this attempt?

thosmos20:03:56

wondering that now. I didn't think so, but I'm looking up how to find the latest tx

marshall20:03:47

If you had that would cause issues

marshall20:03:59

You can't fork history

thosmos21:03:03

I just did a repl on the destination system and am seeing the new data at the end of the log with the right :t of 140415, so at least it's clear that the data is there in the DB. If the history had forked, would the datoms from the restore be in the log, but be inaccessible for any reason?

marshall21:03:53

Do you mean it's in the log but you can't find it with query?

thosmos21:03:20

Oh I see, user error, I was looking at an old derived view on the other end, NOT the actual db value

marshall21:03:36

That' would do it

thosmos21:03:43

thank you for you help!

marshall21:03:49

Sure!

thosmos21:03:10

usually the most obvious explanation 😉