zfs backup script cannot receive destination zpool is renamed
Hello I have an issue with a backup script for ZFS snapshots:
basically the break down of the script is this:
### START OF SCRIPT
# These variables are named first because they are nested in other variables.
snap_prefix=snap
retention=10
# Full paths to these utilities are needed when running the script from cron.
#date=/usr/bin/date
GDATE="/opt/csw/bin/gdate"
grep=/usr/bin/grep
#mbuffer=/usr/local/bin/mbuffer
sed=/usr/bin/sed
sort=/usr/bin/sort
xargs=/usr/bin/xargs
zfs=/sbin/zfs
src_0="ServerStoreR10SSD"
dst_0="zpoolRZ5SATA3/backuppool4/ServerStoreR10SSD"
host="root@hostbk"
today="$snap_prefix-`date +%Y%m%d`"
#yesterday="$snap_prefix-`date -v -1d +%Y%m%d`"
yesterday=$snap_prefix-`$GDATE -d "-1 day" +"%Y%m%d"`
snap_today="$src_0@$today"
snap_yesterday="$src_0@$yesterday"
snap_old=`$zfs list -t snapshot -o name | $grep "$src_0@$snap_prefix*" | $sort -r | $sed 1,${retention}d | $sort | $xargs -n 1`
log=/root/bin/zfsreplication/cronlog/ServerStoreR10SSD.txt
# Create a blank line between the previous log entry and this one.
echo >> $log
# Print the name of the script.
echo "zfsrep_ServerStoreR10SSD.sh" >> $log
# Print the current date/time.
$date >> $log
echo >> $log
# Look for today's snapshot and, if not found, create it.
if $zfs list -H -o name -t snapshot | $sort | $grep "$snap_today$" > /dev/null
then
echo "Today's snapshot '$snap_today' already exists." >> $log
# Uncomment if you want the script to exit when it does not create today's snapshot:
#exit 1
else
echo "Taking today's snapshot: $snap_today" >> $log
$zfs snapshot -r $snap_today >> $log 2>&1
fi
echo >> $log
# Look for yesterday snapshot and, if found, perform incremental replication, else print error message.
if $zfs list -H -o name -t snapshot | $sort | $grep "$snap_yesterday$" > /dev/null
then
echo "Yesterday's snapshot '$snap_yesterday' exists. Proceeding with replication..." >> $log
$zfs send -R -i $snap_yesterday $snap_today | ssh $host $zfs receive -vudF $dst_0 >> $log 2>&1
#For use in local snapshots
#$zfs send -R -i $snap_yesterday $snap_today | $zfs receive -vudF $dst_0 >> $log 2>&1
echo >> $log
echo "Replication complete." >> $log
else
echo "Error: Replication not completed. Missing yesterday's snapshot." >> $log
fi
echo >> $log
# Remove snapshot(s) older than the value assigned to $retention.
echo "Attempting to destroy old snapshots..." >> $log
if [ -n "$snap_old" ]
then
echo "Destroying the following old snapshots:" >> $log
echo "$snap_old" >> $log
$zfs list -t snapshot -o name | $grep "$src_0@$snap_prefix*" | $sort -r
| $sed 1,${retention}d | $sort | $xargs -n 1 $zfs destroy -r >> $log 2>&1
else
echo "Could not find any snapshots to destroy." >> $log
fi
# Mark the end of the script with a delimiter.
echo "**********" >> $log
# END OF SCRIPT
~
the log shows the following
Yesterday's snapshot 'ServerStoreR10SSD@snap-20170419' exists. Proceeding with replication... cannot receive: specified fs (zpoolRZ5SATA3/backuppool4/ServerStoreR10SSD) does not exist attempting destroy zpoolRZ5SATA3/backuppool4/ServerStoreR10SSD failed - trying rename zpoolRZ5SATA3/backuppool4/ServerStoreR10SSD to zpoolRZ5SATA3/backuppool4/ServerStoreR10SSDrecv-5424-1 cannot open 'zpoolRZ5SATA3/backuppool4/ServerStoreR10SSD': dataset does not exist
The script was successfully up until one point when i had a power outage. The main issue is that every time it runs the incremental portion the receiving zfs pool gets renamed to something weird like "..recv-5424-1" hence it cannot open the destination pool and the backup fails...
any suggestions please?
Ваш сценарий не показывает операции переименовать или уничтожить , и мы не знаем исходный и целевой снимки, поэтому этот ответ является общим советом которые вы можете применить к своей ситуации:
Возможная причина ошибки
Для работы инкрементального ZFS send / recv вам всегда нужны снимки N и N-1 на исходная сторона и N-1 на целевой стороне. Затем вы отправите дельту (разницу) между N-1 и N целевой стороне, где она станет N . После этого вы можете удалить N-1 в источнике и повторить процесс.
Немедленное исправление на данный момент
Если один из ваших снимков не соответствует этой системе, например, потому что он был удален или переименовано, у вас есть два возможных способа исправить это:
- Удалить все данные на удаленной стороне, затем выполнить полную / начальную / нормальную отправку / получение. Это займет больше времени, но вам не придется много искать и устранять неполадки.
- Выясните, что именно не так, и исправьте все проблемы вручную, если возможно (это может быть невозможно, если вы уже удалили нужные снимки).
Усовершенствования для решения будущих проблем
Помимо этого, вы должны проверить поток сценария, чтобы увидеть, как эта ошибка появилась. Это помогает преобразовать его в более мелкие функции, такие как send_initial , send_diff , create_snap , delete_snap и т. Д., Чтобы вы могли получить более четкое представление о том, что происходит когда. Затем нарисуйте диаграмму конечного автомата (DFA) с возможными ветвлениями и потоками и посмотрите на каждое изменение состояния: что произойдет, если возникнут ошибки (потеря сети, отключение питания, пользователь отменяет сценарий, отказано в разрешении, ...) и как вы можете смягчить их ?
Если это слишком много работы, вы также можете использовать существующие решения, которые уже устранили эти проблемы. Для некоторых из них, посмотрите этот вопрос двухнедельной давности .
в моем исходном списке zfs
ServerStoreR10SSD 380G 321G 44.9K /ServerStoreR10SSD
ServerStoreR10SSD/DataStore2R10SSD 380G 321G 296G /ServerStoreR10SSD/DataStore2R10SSD
в моем источнике снимки:
ServerStoreR10SSD@snap-20170411 0 - 44.9K -
ServerStoreR10SSD@snap-20170412 0 - 44.9K -
ServerStoreR10SSD@snap-20170413 0 - 44.9K -
ServerStoreR10SSD@snap-20170414 0 - 44.9K -
ServerStoreR10SSD@snap-20170415 0 - 44.9K -
ServerStoreR10SSD@snap-20170416 0 - 44.9K -
ServerStoreR10SSD@snap-20170417 0 - 44.9K -
ServerStoreR10SSD@snap-20170418 0 - 44.9K -
ServerStoreR10SSD@snap-20170419 0 - 44.9K -
ServerStoreR10SSD@snap-20170420 0 - 44.9K -
ServerStoreR10SSD@snap-20170421 0 - 44.9K -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170411 8.77G - 295G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170412 3.95G - 295G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170413 3.11G - 295G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170414 2.99G - 295G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170415 5.61G - 296G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170416 3.31G - 296G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170417 2.76G - 296G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170418 3.74G - 296G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170419 3.65G - 296G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170420 2.72G - 296G -
ServerStoreR10SSD/DataStore2R10SSD@snap-20170421 2.27G - 296G -
список zfs в моем назначении
zpoolRZ5SATA3/backuppool3 1.19T 1.77T 202K /zpoolRZ5SATA3/backuppool3
zpoolRZ5SATA3/backuppool3/DataStoreR10
в моем пункте назначения список моментальных снимков:
zpoolRZ5SATA3/backuppool4@moving 139K - 202K -
zpoolRZ5SATA3/backuppool4/ServerStoreR10SSDrecv-9540-1/DataStore2R10SSD@snap-20170418 11.8G - 296G -
zpoolRZ5SATA3/backuppool4/ServerStoreR10SSDrecv-9540-1/DataStore2R10SSD@snap-20170419 3.67G - 296G -
zpoolRZ5SATA3/backuppool4/ServerStoreR10SSDrecv-9540-1/DataStore2R10SSD@snap-20170420 0 - 296G -