Search Engine: Elastic

Article ID: 131213, created on Jul 31, 2017, last review on Jul 31, 2017

  • Applies to:
  • Operations Automation

Symptoms

A task to restore an NG webspace fails after running for several hours with the following error:

Internal error: std::bad_alloc

The webspace contains a huge amount of files (~ more than 300 000).

Cause

The behavior is planned to be improved in scope of internal request POA-79137 (pleskd fails to restore webspace in case there are about 300 000 files).

Resolution

  1. Stop OA Agent service on the web server node:

    Since OA 7.0:

    # service pa-agent stop
    

    Before OA 7.0:

    # service pem stop
    
  2. Cancel the task.
  3. Find the Agent Log message from the start time of the task and find the exact location of the backup archive:

    Jul 31 07:21:47.935 : DBG [task:19847817:70520 11068:686512:b07feb70 lib ]: [ HCL::HCLProcessor::process] Processing RESTORE(ctri="CTRI: VE_ID:0 HOST:112", tarname="/backups/backup_data-2122.tar"):
    
    Jul 31 07:21:47.959 : DBG [task:19847817:70520 11068:686512:b07feb70 pleskd ]: [ do_restore] Send delegated request https://192.0.2.2:8352/restore
    
  4. Copy the archive from the backup node (192.0.2.2 from the log messages above):

    # scp /backups/backup_data-2122.tar root@192.0.2.4:/tmp
    
  5. Hint: in case the size of free RAM is much larger than the size of the backup archive, it is possible to put the file directly into RAM space to increase the restore time greatly:

    # mount -t tmpfs tmpfs /mnt
    # mv /tmp/backup_data-2122.tar /mnt
    
  6. Restore the archive (run it in screen to avoid accidental interruption):

    # tar xf /mnt/backup_date-2122.tar -C /
    

5356b422f65bdad1c3e9edca5d74a1ae caea8340e2d186a540518d08602aa065 e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF