Opened 7 years ago

Closed 6 years ago

#818 closed defect (worksforme)

Data not restored after performing Mondo restore from NFS

Reported by: Sagar Ippili Owned by: Bruno Cornec
Priority: highest Milestone: 3.0.5
Component: mondo Version: 3.0.4
Severity: blocker Keywords: Mondo Restore
Cc:

Description

Issue : After successful completion of restore(no issues/errors/warnings reported) by Mondo, the server rebooted. We found that the data that was removed after backup was not restored and the data created after the backup was still available.

Hence, although Mondo GUI claims that restore has been completed successfully, we cannot see the old backed up data after restoration by Mondo.

Steps Performed :

1) Backup using the below command :

/usr/sbin/mondoarchive -On nfs4://bgelx129:/nfsshare -k /boot/vmlinuz-3.0.101-100-default -d bgelx131 -N -I '/' -E '/opt/mondo_lkRtrL|/var/lib/ntp/proc|/dev/mapper/*|/dev/md/*|/dev/sdf*|/dev/sdc*|/dev/sde*|/dev/sdb*|/dev/sdg*|/dev/sdd*' -s 4380m -p bgelx131_BCK_20170705_154618 -S /opt/mondo-scratch -T /opt/mondo-tmp -f /dev/sda2

2) Boot up from the first ISO created(i.e bgelx131_BCK_20170705_154618-1.iso) to Mondo Restore top level window.

3) Selected "Exit to Shell", created temporary mount directory and mounted the NFS server's share location.

4) Executed mondorestore to open the top level window and selected "Automatically"

5) Selected "Net mount" and entered respective details like Network User, Network Share, etc.,

7) Restore completed and rebooted the server.

9) Logged on to the restored server and verified if the deleted files are restored, but observed that they are not restored.

Also, unable to find the /var/log/mondorestore.log although Mondo claims that it has restored the system successfully.

Attachments (2)

Logs.zip (99.3 KB ) - added by Sagar Ippili 7 years ago.
Attached zip file containing mindi.log and mondoarchive.log
mondorestore.zip (52.0 KB ) - added by Sagar Ippili 7 years ago.

Download all attachments as: .zip

Change History (8)

by Sagar Ippili, 7 years ago

Attachment: Logs.zip added

Attached zip file containing mindi.log and mondoarchive.log

comment:1 by Bruno Cornec, 7 years ago

Before rebooting, capture the mondorestore.log file. Without it, there is no way I can help with this issue.

Your version is pretty old, and you should move to the 3.2 branch instead. THere won't be any evolution on the 3.0 one.

comment:2 by Sagar Ippili, 7 years ago

Hi Bruno,

I tried to copy the log to a directory(here, I used /usr), but I cannot see the same after reboot.

Could you please suggest a way to capture it.

comment:3 by Bruno Cornec, 7 years ago

You should mount a USB Key and copy your files to it if you want to get them back. Another possibility is to use a shared NFS drive.

by Sagar Ippili, 7 years ago

Attachment: mondorestore.zip added

comment:4 by Sagar Ippili, 7 years ago

Attached the mondorestore log. Could you please check now.

comment:5 by Bruno Cornec, 7 years ago

Status: newassigned

It seems that mondorestore didn't format some FS:

running: sh -c 'echo -en "y\ny\ny\n" | mkswap /dev/sde1' > /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.tmp 2> /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
Setting up swapspace version 1, size = 146483320 KiB
no label, UUID=a670cb5a-7ad6-4c4d-983d-7bf53ee7a08e
mkswap: /dev/sde1: warning: don't erase bootbits sectors
(dos partition table detected). Use -f to force.
--------------------------------end of output------------------------------

This has been fixed in more recent versions of mondorestore as in 3.2.2 below:

../../tags/3.2.2/mondo/src/mondorestore/mondo-prep.c:   mr_asprintf(program, "mkswap -f");
../../tags/3.2.2//mondo/src/restore-scripts/mondo/mr-label-partitions-as-necessary:                                 command="mkswap -f $opttun $label $mountpt"

A workaround would be to erase with dd the partitions before usage.

Also I see:

running: sh -c 'echo -en "y\ny\ny\n" | mkfs -t ext3 -F -q /dev/sda2' > /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.tmp 2> /tmp/mondo.tmp.3ZBBAn/mondo-run-prog-thing.err
--------------------------------start of output-----------------------------
mkfs.ext3: No such file or directory while trying to determine filesystem size
--------------------------------end of output------------------------------

There was an error saying that parioning didn't happened correctly. For your tests, to be sure, the best approach is to erase disks before operation (dd) or change them if possible.

However as the FS was previously existing, it could be mounted as /dev/sda2 (as shown in the log) and retsoration occured on it (so it restored files, but kept new ones for example).

This is strange as that command was backed up by mindi in the boot environment (it's analyzed in your mindi.log) with it's deps:

/sbin/mkfs.ext3
/lib64/libext2fs.so.2
/lib64/libext2fs.so.2
/lib64/libext2fs.so.2.4
/lib64/libcom_err.so.2
/lib64/libcom_err.so.2
/lib64/libcom_err.so.2.1
/lib64/libblkid.so.1
/lib64/libblkid.so.1
/lib64/libblkid.so.1.1.0
/lib64/libuuid.so.1
/lib64/libuuid.so.1
/lib64/libuuid.so.1.3.0
/lib64/libe2p.so.2
/lib64/libe2p.so.2
/lib64/libe2p.so.2.3
/lib64/libc.so.6
/lib64/libc.so.6
/lib64/libc-2.11.3.so
/lib64/libpthread.so.0
/lib64/libpthread.so.0
/lib64/libpthread-2.11.3.so
/lib64/ld-linux-x86-64.so.2
/lib64/ld-linux-x86-64.so.2
/lib64/ld-2.11.3.so

So I don't know why it's not accessible at restore time here.

Could you at restore time, once the boot has been performed and before restoring go to the shell and type mkfs -t ext3 -F /dev/sda2 and provide the messages reported please ?

Also give the result of ls -al /sbin/mkfs.ext3 (should be there)

comment:6 by Bruno Cornec, 6 years ago

Resolution: worksforme
Status: assignedclosed
Note: See TracTickets for help on using tickets.