Restore Failed

128 views
Skip to first unread message

Scott Richesson

unread,
Feb 4, 2022, 12:16:31 PM2/4/22
to sipxcom-users
Trying to take advantage of a snow-day to upgrade to the latest version of sipxcom (Centos 7) from a 2019.something Centos 6. 

Getting "Restore Failed" in the job log.

Any ideas where I should look for a cause?

Scott

Scott Richesson

unread,
Feb 4, 2022, 12:22:01 PM2/4/22
to sipxcom-users
This is in the restore.log:

sipx-archive
Restore uses /var/sipxdata/tmp as temporary dir.
version
DROP EXTENSION
ERROR:  language "plpgsql" already exists
dump/
dump/profiles/
dump/profiles/userProfile.bson
dump/profiles/fs.files.metadata.json
dump/profiles/fs.chunks.bson
dump/profiles/fs.chunks.metadata.json
dump/profiles/userProfile.metadata.json
dump/profiles/fs.files.bson
MongoDB shell version v3.6.11
connecting to: mongodb://127.0.0.1:27017/profiles?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("5095592f-5808-42c6-b7f0-0f0d3aa3f1b7") }
MongoDB server version: 3.6.11
2022-02-04T12:16:33.269-0500 E QUERY    [thread1] Error: remove needs a query :
DBCollection.prototype._parseRemove@src/mongo/shell/collection.js:357:1
DBCollection.prototype.remove@src/mongo/shell/collection.js:382:18
@(shell eval):1:45
@(shell eval):1:1
2022-02-04T12:16:33.294-0500        the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead
2022-02-04T12:16:33.294-0500        building a list of collections to restore from /var/sipxdata/tmp/dump/profiles dir
2022-02-04T12:16:33.298-0500        reading metadata for profiles.userProfile from /var/sipxdata/tmp/dump/profiles/userProfile.metadata.json
2022-02-04T12:16:33.298-0500        restoring profiles.userProfile from /var/sipxdata/tmp/dump/profiles/userProfile.bson
2022-02-04T12:16:33.300-0500        reading metadata for profiles.fs.chunks from /var/sipxdata/tmp/dump/profiles/fs.chunks.metadata.json
2022-02-04T12:16:33.300-0500        restoring profiles.fs.chunks from /var/sipxdata/tmp/dump/profiles/fs.chunks.bson
2022-02-04T12:16:33.302-0500        reading metadata for profiles.fs.files from /var/sipxdata/tmp/dump/profiles/fs.files.metadata.json
2022-02-04T12:16:33.302-0500        restoring profiles.fs.files from /var/sipxdata/tmp/dump/profiles/fs.files.bson
2022-02-04T12:16:33.308-0500        error: multiple errors in bulk operation:
  - E11000 duplicate key error collection: profiles.fs.files index: _id_ dup key: { : ObjectId('51847344e4b0112527a5adc6') }
  - E11000 duplicate key error collection: profiles.fs.files index: _id_ dup key: { : ObjectId('53343c37e4b0a67dfd78e3a5') }

2022-02-04T12:16:33.309-0500        restoring indexes for collection profiles.fs.files from metadata
2022-02-04T12:16:33.309-0500        finished restoring profiles.fs.files (2 documents)
2022-02-04T12:16:33.312-0500        error: multiple errors in bulk operation:
  - E11000 duplicate key error collection: profiles.fs.chunks index: _id_ dup key: { : ObjectId('51847344e4b0112527a5adc7') }
  - E11000 duplicate key error collection: profiles.fs.chunks index: _id_ dup key: { : ObjectId('53343c37e4b0a67dfd78e3a6') }

2022-02-04T12:16:33.312-0500        restoring indexes for collection profiles.fs.chunks from metadata
2022-02-04T12:16:33.314-0500        Failed: profiles.fs.chunks: error creating indexes for profiles.fs.chunks: createIndex error: Index with name: files_id_1_n_1 already exists with different options
Failed to restore user profiles database
Create or restore configuration to/from an archive file.
        --backup <archive>           Restore the specified Configuration archive.

Backup options:
        --restore <archive>          Restore the specified Configuration archive.
        --verbose                    Restore the specified Configuration archive.

Restore options:
        --no-device-files            Do not include device uploaded files in backup.
        --tmp-dir <tmp-dir>          Temporary backup file location
        --ipaddress <address>        IP Address. Default xxx.
        --domain <domain>            SIP domain for new system. i.e. example.org. Default is to keep domain from archive
        --fqdn <fqdn of primary machine>
                                     Set FQDN of this primary machine
        --dryrun                     Don't actually restore db, but test the db migration process.
        --reset-pin default-pin      Blindly reset all pins to given pin.
        --reset-password default-password
                                     Blindly reset all user portal passwords. Password is also used for IM and call center.
        --crack-pin default-pin      When changing the domain and when restoring from backups for versions 4.4.0, attempt to recover original Voicemail PIN by brute force. If unsuccessful, reset users pin. Also, if user does not have an IM password, this pin will be used for that as well.
        --crack-passwd default-passwd
                                     When changing the domain and when restoring from backups for versions 4.4.0, attempt to recover original user PIN by brute force. If unsuccessful, reset users pintoken. Also, if user does not have an IM password, this pin will be usedfor that as well.
        --crack-pin-len length       Maximum length of PIN to attempt. Default is 4. Higher values take exponentially more time.
        --no-restart                 Use this flag if sipxconfig is already stopped and you do not want this script to re-stop or start sipxconfig after it's done.
/usr/bin/sipx-archive:495:in `block in run': RESTORE error: Failed to restore configuration.tar.gz using command sipxconfig-archive --restore /var/sipxdata/tmp/restore/configuration.tar.gz --tmp-dir /var/sipxdata/tmp (RuntimeError)
        from /usr/bin/sipx-archive:489:in `each'
        from /usr/bin/sipx-archive:489:in `run'
        from /usr/bin/sipx-archive:568:in `<main>'
/usr/bin/sipx-archive:203:in `block in run': RESTORE FAILED: Could not complete restore on host xxxx (RuntimeError)
        from /usr/bin/sipx-archive:190:in `each'
        from /usr/bin/sipx-archive:190:in `run'
        from /usr/bin/sipx-archive:568:in `<main>'

Scott Richesson

unread,
Feb 4, 2022, 12:51:13 PM2/4/22
to sipxcom-users
Exact from version is 19.04.20190419050314 2019-04-19EDT05:04:39

Matt Keys

unread,
Feb 8, 2022, 10:28:00 AM2/8/22
to sipxcom-users
You can't upgrade major OS like CentOS 6 to CentOS 7. 

This requires a fresh install of centos7 and restoration of the configuration.tar.gz from the centos 6 server. Refer to the installation instructions on the wiki. 


srich...@gmail.com

unread,
Feb 8, 2022, 10:36:49 AM2/8/22
to Matt Keys, sipxcom-users

Yes, that is exactly what I am trying to do……   The error is on the restore of the config.   Thoughts?

 

Scott

--
You received this message because you are subscribed to a topic in the Google Groups "sipxcom-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sipxcom-users/qnlAIXJ9IEk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sipxcom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/af186f44-2c9e-497b-a659-cc6432ecae16n%40googlegroups.com.

Iuliu Blaga

unread,
Feb 8, 2022, 10:54:30 AM2/8/22
to srich...@gmail.com, Matt Keys, sipxcom-users
Please try this

You can make that faulty backup work as well if you follow these steps below. Make sure to use the web interface to restore. 1. BEFORE the restore: mongo use profiles show collections db.getCollection('fs.chunks').dropIndex('files_id_1_n_1') 2. then RESTORE the config backup 3. after the restore: mongo use profiles show collections db.getCollection('fs.chunks').reIndex() This is all. "show collections" is a list command that can be taken out but makes sure you are on the right database.

You received this message because you are subscribed to the Google Groups "sipxcom-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sipxcom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sipxcom-users/000701d81d01%24af14fa30%240d3eee90%24%40gmail.com.


--

 

Iuliu Blaga
Sr. Support Engineer
 
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.

srich...@gmail.com

unread,
Feb 8, 2022, 11:03:03 AM2/8/22
to Iuliu Blaga, Matt Keys, sipxcom-users

Great.  Thanks.  Will try tonight.

 

Image removed by sender.

Image removed by sender.

Image removed by sender.

Image removed by sender.

Image removed by sender.

 

~WRD0000.jpg

Scott Richesson

unread,
Feb 8, 2022, 7:43:34 PM2/8/22
to sipxcom-users
So, yes the restore went through.  Thanks Iuliu!

I ran out of time, and I'll have to try again another day, though and be much more careful with names.  Not sure what happened, but my server name came through as sip.mydomain.com.sip.mydomain.com!

Scott

Iuliu Blaga

unread,
Feb 9, 2022, 9:00:04 AM2/9/22
to Scott Richesson, sipxcom-users
Yeah that happens from time to time, we are not sure why. Please try to play around with the option to keep/discard the domain name from the backup



--

 

 

Scott Richesson

unread,
May 30, 2022, 10:50:29 AM5/30/22
to sipxcom-users
Just got back to this.  Yes, checking the boxes to "Keep" the domain name/host name solved the issue.  I seem to be good to go.  Thanks.

Iuliu Blaga

unread,
May 30, 2022, 11:25:53 AM5/30/22
to Scott Richesson, sipxcom-users
Great news! Take care

Reply all
Reply to author
Forward
0 new messages