You can associate the /dev/loop3
with cinder-volumes
files as using /etc/rc.d/rc.local
conf.
CentOS 6 or less
# vim /etc/rc.d/rc.local
mknod -m 660 /dev/loop3 b 7 3
losetup /dev/loop3 /path/to/cinder-volumes
CentOS 7
# vim /etc/rc.d/rc.local
mknod -m 660 /dev/loop3 b 7 3
losetup /dev/loop3 /path/to/cinder-volumes
After modifying, you set the execution flag to /etc/rc.d/rc.local
# chmod u+x /etc/rc.d/rc.local
And more checks your OS rc-local.service as following,
# systemctl list-unit-files rc-local.service
UNIT FILE STATE
rc-local.service static
or
UNIT FILE STATE
rc-local.service disable
If the state is disable, you can be enable the rc-local service, but the state is static is not any more conf.
# systemctl enable rc-local.service
Updated: Adding restore steps based on hypothesis that refer from questions.
★★★In advance, I defined that these steps are just written as the provision of information, I won't be not responsible for data-loss caused by these steps.★★★
Prepare the other server having same specifications as possible as you can.
backup the data (here is cinder-volumes
file) with dd or cp commands
check the backup file whether same original data with md5sum
command.
the backup data transfer to the new server for testing.
test command; losetup /dev/loop3 /path/to/cinder-volumes
and blkid
command for check UUID whether same with the original loop3 device.
More tests was always conducted on the new server, not production or important environments.
the loop3 or loopN device is virtual device for using the non-block device as of block device. It is just mapping interfaces. The loop3 device is disappeared but if cinder-volumes
is clear, no problem.
I hope you it's helpful.