Simple asset.archive.restore fails.

[Stephen Crawley]

I'm trying to test simple disaster recovery for a store.

This is my backup script:

server.database.backup :url file:///$dir/database
server.database.lock :action abort \
    :msg "The DaRIS database and stores are being backed up"
asset.archive.create :url file:///$dir/assets.aar
server.database.unlock

That runs fine - both database and asset backups are created in the expected place

Restoring the database using this command works (apparently):

> server.database.restore :url file:///mnt/mf-volatile.save/backups/2014-02-04/database
    :nb-schemas "2"
    :nb-clusters "31"
    :nb-objects "2424"
    :note "The server must be restarted after restoring.. will automatically restart."

However, asset restore fails:

> asset.archive.restore :url file:///mnt/mf-volatile.save/backups/2014-02-04/assets.aar
error: executing asset.archive.restore: [arc.mf.server.Services$ExServiceError]: call to service 'asset.archive.restore' failed: Error when restoring asset entry 'assets/system/icons/type/text/xml-0': error when restoring XML: This is not an asset archive. Unexpected entry 'assets/system/icons/type/text/xml-0'

Adding ":ignore-unknown true" or ":overwrite true" makes no difference.

What am I doing wrong? 

(I am running "3.8.050" ...)

-- Steve

[Stephen Crawley]

Ermm ... in the light of the responses to my previous question ... is it correct to say that the "asset.archive.create/restore" approach is not viable?

[Jason Lohrey]

It should be viable. In fact, we (everyone) uses it a lot. It might be that a gross archive creation has resulted in uncovering a defect. We’ll see if we can replicate.

The best method for backing up is:

server.database.backup — since that backs up all clusters and data structures - but not the data.

For disaster recovery, you should replicate to another node. That will take the asset metadata, and content (data).

Jason

On 4 Feb 2014, at 2:16 pm, Stephen Crawley <crawley...@gmail.com> wrote:

Ermm ... in the light of the responses to my previous question ... is it correct to say that the "asset.archive.create/restore" approach is not viable?

--
You received this message because you are subscribed to the Google Groups "mediaflux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mediaflux+...@googlegroups.com.
To post to this group, send email to medi...@googlegroups.com.
Visit this group at http://groups.google.com/group/mediaflux.
For more options, visit https://groups.google.com/groups/opt_out.

JASON LOHREY

Chief Technical Officer

[Stephen Crawley]

I understand that replication may be the ideal solution for some people.  Especially people with lots of money to throw at the problem ...

However, I'm trying put together something that would allow a researcher or small group to spin up a stand-alone Mediaflux instance on a NeCTAR node ... for the cost of a single Mediaflux license.  Running a second Mediaflux instance solely as a backup is wasteful, especially since the researcher / group typically has to buy an extra license in order to implement it.

At this stage, I'm leaning towards incremental backups using GNU tar, and saving the resultant files to Swift object store or (in the future) tape.  But if we can figure out how to get "asset.archive.create/restore" to do the job, I'll revisit that option.

-- Steve

[Brian O'Connor]

Hello Stephen

you have found a bug!

Usually when customers use asset.archive.create it is to archive a
specific namespace or store to send elsewhere.

so you would use the :where clause

ie

asset.archive.create :url /tmp/backup.aar :where "namespace>=data"
or
asset.archive.create :url /tmp/backup.aar :where content store 'data'

you used

asset.archive.create :url /tmp/backup.aar

This archives everything including all the system stuff... one of the
system files is actually called 'xml' and this name was not handled...
so the
archive restore failed.

We are fixing the problem as we speak!

To confirm could you try an asset.archive.create and restore using the
":where" clause as detailed above?

thanks


Brian O'Connor
ARCITECTA
5/26-36 High Street
Northcote Victoria
Australia 3070
T:+61 3 86838523
M:+61 417746452
http://www.arcitecta.com

On 4/02/2014 14:42, Jason Lohrey wrote:
> It should be viable. In fact, we (everyone) uses it a lot. It might be

> that a /gross/ archive creation has resulted in uncovering a defect.

> We’ll see if we can replicate.
>
> The best method for backing up is:
>
> server.database.backup — since that backs up all clusters and data
> structures - but not the data.
>
> For disaster recovery, you should replicate to another node. That will
> take the asset metadata, and content (data).
>
> Jason
>
>
> On 4 Feb 2014, at 2:16 pm, Stephen Crawley <crawley...@gmail.com

> <mailto:crawley...@gmail.com>> wrote:
>
>> Ermm ... in the light of the responses to my previous question ... is
>> it correct to say that the "asset.archive.create/restore" approach is
>> not viable?
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "mediaflux" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to mediaflux+...@googlegroups.com

>> <mailto:mediaflux+...@googlegroups.com>.

>> To post to this group, send email to medi...@googlegroups.com

>> <mailto:medi...@googlegroups.com>.

[Brian O'Connor]

oh I should say of course that I created the 'data' namespace and the
'data' store

you should replace the names with whatever you like (apart from the "db"
store ... its where the problem file is)

--

[Stephen Crawley]

OK.  I did that. 

asset.archive.create :url file:///$dir/pssd.aar :where content store 'pssd'

Now when I attempt to restore, I get this:

> asset.archive.restore :url file:///mnt/mf-volatile.save/backups/2014-02-05/pssd.aar
    :count "0"
>

... and judging from what I'm observing via the DaRIS portal, the "count 0" really does mean that no objects were restored.

The "pssd.aar" archive really does exist, and is the one created above.  It is 1.7Gb in size containing tens of objects.  And I'm doing this against a freshly restored database.

-- Steve

[Brian O'Connor]

The restore will skip objects that checksum as identical. So if the
object exists then the restore will skip them.

try deleting an asset and then try the restore again, or restore to a
different machine.


i.e.

>asset.query :where content store 'pssd'

will give you the asset ids

then

>asset.destroy :id <id>
>asset.archive.restore :url file:///mnt/mf-volatile.save/backups/2014-02-05/pssd.aar

or add overwrite.


>asset.archive.restore :overwrite true :url ....

(carefull.....)

> <crawley...@gmail.com <javascript:>

> >> <mailto:crawley...@gmail.com <javascript:>>> wrote:
> >>
> >>> Ermm ... in the light of the responses to my previous question
> ...
> >>> is it correct to say that the "asset.archive.create/restore"
> >>> approach is not viable?
> >>>
> >>> --
> >>> You received this message because you are subscribed to the
> Google
> >>> Groups "mediaflux" group.
> >>> To unsubscribe from this group and stop receiving emails from it,

> >>> send an email to mediaflux+...@googlegroups.com <javascript:>
> >>> <mailto:mediaflux+...@googlegroups.com <javascript:>>.

> >>> To post to this group, send email to medi...@googlegroups.com

> <javascript:>
> >>> <mailto:medi...@googlegroups.com <javascript:>>.

> >>> Visit this group at http://groups.google.com/group/mediaflux

> <http://groups.google.com/group/mediaflux>.

> >>> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

> >>
> >> JASON LOHREY
> >> Chief Technical Officer
> >>
> >>
> >> --
> >> You received this message because you are subscribed to the Google
> >> Groups "mediaflux" group.
> >> To unsubscribe from this group and stop receiving emails from it,

> >> send an email to mediaflux+...@googlegroups.com <javascript:>.

> >> To post to this group, send email to medi...@googlegroups.com

> <javascript:>.

> >> Visit this group at http://groups.google.com/group/mediaflux

> <http://groups.google.com/group/mediaflux>.

> >> For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[Stephen Crawley]

I've already tried ':overwrite true'.  It made no difference.

Based on what you are saying, there seems to be a mismatch between the capabilities of 'asset.archive.restore' and my use-case.  I simply want to be able to restore the entire database and store contents from "the backups" into an unpopulated Mediaflux instance.  For my use-case, I think that the service needs to check if the asset files actually exist in the file system (at the expected place) ... and restore them if they don't exist.

[Stephen Crawley]

Also

> asset.store.list
    :store -id "1"
        :type "database"
        :name "db"
    :store -id "2"
        :type "file-system"
        :name "pssd"
    :store -id "3"
        :type "file-system"
        :name "dicom"

> asset.query :where content store 'pssd'

>

Clearly, the store exists, and there were no pre-existing assets in it.  The 'asset.archive.restore' command is failing to restore stuff for some other reasons.

-- Steve

[Jason Lohrey]

Asset archive restore is working precisely as intended/designed.

Asset archive restore checks to see whether:

a) The asset exists, and

b) If it does, whether the metadata and/or the content have changed.

If neither are satisfied, then no update, which is why you got zero (0) updates.

Asset archive restore can reconcile changes from many different nodes, so it reconnects with the source asset(s) when looping back - it does this by keeping track of the server (UUID) that made any modifications (metadata and/or content and/or tags etc.)

Therefore, the correct test is to:

1/ archive

2/ create a new database (simulates complete failure)

3/ restore

or:

1/ archive

2/ delete the/some assets (simulates partial failure)

3/ restore

Jason

[Jason Lohrey]

Brian has just informed me what your use case is — you want to restore missing content/data (but the database already exists).

The archive in the version that you have does not support restoration of missing content. We have recently added the ability to restore missing content when restoring the archive.

The archive version you have does not support the option, restore-missing-content, specifically for this purpose:

:restore-missing-content (type=boolean, min-occurs=0, max-occurs=1) If set to true then further comparison is made to determine if existing content is physically missing an needs to be recovered. Defaults to false.

Jason

<Arcitecta.png>

--
You received this message because you are subscribed to the Google Groups "mediaflux" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mediaflux+...@googlegroups.com.
To post to this group, send email to medi...@googlegroups.com.
Visit this group at http://groups.google.com/group/mediaflux.
For more options, visit https://groups.google.com/groups/opt_out.