Opened 8 years ago
Closed 7 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)
Change History (8)
by , 8 years ago
comment:1 by , 8 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 , 8 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 , 8 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 , 8 years ago
Attachment: | mondorestore.zip added |
---|
comment:5 by , 8 years ago
Status: | new → assigned |
---|
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 , 7 years ago
Resolution: | → worksforme |
---|---|
Status: | assigned → closed |
Attached zip file containing mindi.log and mondoarchive.log