Warren Daly <[email protected]> writes:
>>>> > When I run s3qladm download-metadata s3://xxxxx
>>>> > I see this:
>>>> >
>>>> > No Name Date
>>>> > 0 s3ql_metadata_bak_0 2013-07-02 11:14:55
>>>> > 1 s3ql_metadata_bak_1 2013-07-01 11:14:14
>>>> > 2 s3ql_metadata_bak_10 2013-06-24 03:34:58
>>>> > 3 s3ql_metadata_bak_2 2013-07-01 03:20:06
>>>> > 4 s3ql_metadata_bak_3 2013-06-30 03:19:49
>>>> > 5 s3ql_metadata_bak_4 2013-06-29 03:13:52
>>>> > 6 s3ql_metadata_bak_5 2013-06-28 14:08:21
>>>> > 7 s3ql_metadata_bak_6 2013-06-28 03:36:40
>>>> > 8 s3ql_metadata_bak_7 2013-06-27 03:36:20
>>>> > 9 s3ql_metadata_bak_8 2013-06-26 03:35:40
>>>> > 10 s3ql_metadata_bak_9 2013-06-25 03:35:20
>>>> >
>>>> > *Why are the backups so old? Surely metadata refreshes at the default
>>>> (24
>>>> > hour) periods? *
>>>>
>>>> It should, unless you pass a different option. What does your
>>>> ~/.s3ql/mount.log file say? It should report whenever metadata is saved.
>
> mount log:
> 2014-06-18 13:07:05.469 [3893] MainThread: [mount] Using 4 upload threads.
> 2014-06-18 13:07:06.476 [3893] MainThread: [mount] Ignoring locally cached
> metadata (outdated).
> 2014-06-18 13:07:06.667 [3893] MainThread: [root] Backend reports that fs
> is still mounted elsewhere, aborting.
[...]
What I meant is, log at the *old* entries in mount.log (or mount.log.1,
mount.log.2, etc) to determine why the metadata backups were not
written.
Was the system ever restarted since 2013-07-02?
Was the file system ever unmounted since 2013-07-02?
How are you starting mount.s3ql? Are you using the
--metadata-upload-interval option?
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
--
You received this message because you are subscribed to the Google Groups
"s3ql" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
