Backup and restore from and to AWS istances (OpenEMR Cloud Express)

AndreaD · June 28, 2021, 1:26pm

Situation
I have two OpenEMR Cloud Express instances on AWS (version 6.0.0)
I am try to backup-and-restore as a way to move data from instance A to instance B

Backup on instance A is done through web interface. Wonderful.
Restore on instance B is done by follow the instructions here:

After

/root/restore.sh --confirm

I get the following error:

restore.sh: confirmation acknowledged, beginning destructive restore …
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Traceback (most recent call last):
File “/usr/bin/duplicity”, line 1532, in
with_tempdir(main)
File “/usr/bin/duplicity”, line 1526, in with_tempdir
fn()
File “/usr/bin/duplicity”, line 1380, in main
do_backup(action)
File “/usr/bin/duplicity”, line 1457, in do_backup
restore(col_stats)
File “/usr/bin/duplicity”, line 722, in restore
restore_get_patched_rop_iter(col_stats)):
File “/usr/bin/duplicity”, line 744, in restore_get_patched_rop_iter
backup_chain = col_stats.get_backup_chain_at_time(time)
File “/usr/lib/python2.7/dist-packages/duplicity/collections.py”, line 970, in get_backup_chain_at_time
raise CollectionsError(“No backup chains found”)
CollectionsError: No backup chains found

recovery: low free memory, temporarily allocating swap space
Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)
no label, UUID=65778b42-6542-4d18-abb0-605b0dcc7331
/root/xrecovery.sh: line 6: cd: /mnt/backups/bkps: No such file or directory
ls: cannot access *-info.log: No such file or directory
recovery: invalid starting point .tar.gz

Any idea how I can investigate it any further?
Thank you very much!
Andrea

stephenwaite · June 28, 2021, 1:30pm

hi @AndreaD, did you place the backup in the new instance?

If necessary, place the compressed backup archive bundle in /root/backups .

AndreaD · June 28, 2021, 1:46pm

Hi @stephenwaite, thanks for the superfast reply.
Yes, I put the tar file in /root/backups/.
And I am root

stephenwaite · June 28, 2021, 2:34pm

looks like even though you aren’t going to use the duplicity backup you should create one on instance B so it creates the needed directories, so run

/etc/cron.daily/duplicity-backups

then the restore script should have what it hopefully needs

AndreaD · June 28, 2021, 4:34pm

Thank you for your suggestion. I am not sure that the command works. The output was:

/etc/cron.daily/duplicity-backups

Command line error: Expected 2 args, got 3
Enter ‘duplicity --help’ for help screen.
Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
No old backup sets found, nothing deleted.

The “/root/restore.sh --confirm” has still the same output.

Any other idea would be very appreciated!

stephenwaite · June 28, 2021, 6:23pm

try editing /etc/cron.daily/duplicity-backups and add the SQLMOUNT environment variable after the else statement or replace the script with the attached file

  SQLMOUNT=$(docker volume inspect lightsail_sqlbackup | jq -r ".[0].Mountpoint")

and run /etc/cron.daily/duplicity-backups again before the restore

duplicity-backups (1.1 KB)

AndreaD · June 28, 2021, 7:06pm

thank you very much! One issue is solved. After duplicating the line
SQLMOUNT=$(docker volume inspect lightsail_sqlbackup | jq -r ".[0].Mountpoint")
after the “else” statement, the
/etc/cron.daily/duplicity-backups worked!
Here the output

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
Last full backup is too old, forcing full backup
--------------[ Backup Statistics ]--------------
StartTime 1624906275.51 (Mon Jun 28 18:51:15 2021)
EndTime 1624906276.04 (Mon Jun 28 18:51:16 2021)
ElapsedTime 0.53 (0.53 seconds)
SourceFiles 13
SourceFileSize 11169450 (10.7 MB)
NewFiles 13
NewFileSize 11169450 (10.7 MB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 13
RawDeltaSize 11124394 (10.6 MB)
TotalDestinationSizeChange 9851091 (9.39 MB)
Errors 0
-------------------------------------------------

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: Mon Jun 28 18:51:15 2021
No old backup sets found, nothing deleted.

However I didn’t understand how to restore my “emr_backup_27-06-2021.tar” file coming from another machine. The /root/backups/ is populated by this files:

drwxr-xr-x 2 root   root        4096 Jun 28 18:38 ./
drwx------ 6 root   root        4096 Jan 17 00:41 ../
-rw------- 1 root   root        4244 Jun 28 18:37 duplicity-full.20210628T183704Z.manifest
-rw------- 1 root   root     9891813 Jun 28 18:37 duplicity-full.20210628T183704Z.vol1.difftar.gz
-rw------- 1 root   root       72829 Jun 28 18:37 duplicity-full-signatures.20210628T183704Z.sigtar.gz
-rw-r--r-- 1 ubuntu ubuntu 171899904 Jun 27 15:22 emr_backup_27-06-2021.tar

and when I do “./restore.sh --confirm” it looks to me that the system is using the “duplicity-full-signatures.20210628T183704Z.sigtar.gz” backup.

I tried (naively?) to remove everything in /root/backups except my “emr_backup_27-06-2021.tar”.
Tried again “./restore.sh --confirm” and got again the same problem:

> Last full backup date: none
> Traceback (most recent call last):
>   File "/usr/bin/duplicity", line 1532, in <module>
>     with_tempdir(main)
>   File "/usr/bin/duplicity", line 1526, in with_tempdir
>     fn()
>   File "/usr/bin/duplicity", line 1380, in main
>     do_backup(action)
>   File "/usr/bin/duplicity", line 1457, in do_backup
>     restore(col_stats)
>   File "/usr/bin/duplicity", line 722, in restore
>     restore_get_patched_rop_iter(col_stats)):
>   File "/usr/bin/duplicity", line 744, in restore_get_patched_rop_iter
>     backup_chain = col_stats.get_backup_chain_at_time(time)
>   File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 970, in get_backup_chain_at_time
>     raise CollectionsError("No backup chains found")
> CollectionsError: No backup chains found

Thank you for you help!

stephenwaite · June 28, 2021, 7:34pm

hi @AndreaD, is this for a US practice?

AndreaD · June 28, 2021, 7:43pm

No, it would be for an Italian no-profit association where many physicians run a small clinic on voluntary basis.

stephenwaite · June 28, 2021, 8:03pm

Ok, nice, thank you.

think that @jesdynf’s instructions

If necessary, place the compressed backup archive bundle in /root/backups .

mean run the edited duplicity-backups script on A and then place that “bundle” from /root/backups on A into B

so basically the backup from the gui is not a native duplicity backup for restore

AndreaD · June 28, 2021, 10:23pm

Thank you much @stephenwaite!

I run the edited duplicity-backups on machine A, transfered the whole bundle in /root/backups in machine B, and restored it.
That worked like a charm!

All the best!
Andrea

jesdynf · June 30, 2021, 5:19pm

Thanks for fixing this up! I can’t believe it’s been in there so long and I never noticed the bug on this branch.