#1168 PR merged: Make USB backup selection work (issue1166)¶
Labels: enhancement, bug, cleanup, fixed / solved / done
jsmeix opened issue at 2017-01-16 13:55:¶
With the current changes in 070_set_backup_archive.sh
and 540_choose_backup_archive.sh it works for me
see
https://github.com/rear/rear/issues/1166
but I need to verify if I didn't break other things.
jsmeix commented at 2017-01-16 14:00:¶
Do not yet merge it.
I need to do more tests and
I need to adapt the documentation.
jsmeix commented at 2017-01-17 11:12:¶
I made the backup selection dialog behave
now reasonably well for me and
I made the USB_RETAIN_BACKUP_NR
description in default.conf less specific about
how many backups / recovery systems will be kept
according to my experience in
https://github.com/rear/rear/issues/1166#issuecomment-273101775
FYI:
How recovery looks now for me
when there is more than one backup detected (excerpts):
RESCUE e205:~ # rear -d -D recover ... Using backup archive '/tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1144/backup.tar.gz' ... Backup archive /tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1057/backup.tar.gz detected. Backup archive /tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1106/backup.tar.gz detected. Backup archive /tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1144/backup.tar.gz detected. Backup archive /tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1149/backup.tar.gz detected. Select a backup archive. 1) 20170117.1057 2) 20170117.1106 3) 20170117.1144 4) 20170117.1149 5) Abort #? 7 Invalid choice 7, try again or abort. #? 4 Using backup archive '/tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1144/backup.tar.gz'. ... Restoring from '/tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1144/backup.tar.gz'...
How recovery looks now for me
when there is only one backup detected
and that backup is even not in the recovery system
i.e. made by a "rear mkrescue" with timestamp "...1447"
and a "rear mkbackuponly" with timestamp "...1149"
(excerpts):
RESCUE e205:~ # rear -d -D recover ... Using backup archive '/tmp/rear.3P14lPqcINr1SD4/outputfs/rear/e205/20170116.1447/backup.tar.gz' Backup archive '/tmp/rear.3P14lPqcINr1SD4/outputfs/rear/e205/20170116.1447/backup.tar.gz' not readable. Need to select another one. ... Backup archive /tmp/rear.3P14lPqcINr1SD4/outputfs/rear/e205/20170117.1149/backup.tar.gz detected. Using backup archive '/tmp/rear.3P14lPqcINr1SD4/outputfs/rear/e205/20170117.1149/backup.tar.gz'. ... Restoring from '/tmp/rear.3P14lPqcINr1SD4/outputfs/rear/e205/20170117.1149/backup.tar.gz'...
I.e. no useless backup selection dialog if there is only one backup
plus automated switch from a non-existing default backup file
to an actually existing (i.e. autodetected) backup file.
Now it looks good to me so that I will merge it soon.
jsmeix commented at 2017-01-17 11:17:¶
I will not merge it soon because there is a bug
in the backup selection
see above:
Select a backup archive. 1) 20170117.1057 2) 20170117.1106 3) 20170117.1144 4) 20170117.1149 5) Abort #? 7 Invalid choice 7, try again or abort. #? 4 Using backup archive '/tmp/rear.Awzw8UJvVE0ZHLp/outputfs/rear/e205/20170117.1144/backup.tar.gz'.
I selected "4) 20170117.1149" but I got "3) 20170117.1144" restored!
jsmeix commented at 2017-01-17 13:40:¶
How embarrassing: I outsmarted myself!
My overclever attempt in
https://github.com/rear/rear/pull/1168/commits/4f6f21ae469877177536bd418d546f7696ccacfe
to run the 'set +x' in a subshell during the backup selection dialog
to easily return to the environment settings of before after the
backup selection dialog makes of course all set variables within
that dialog useless after returning from that subshell which results
that the initially set and reported RESTORE_ARCHIVES value
is actually used.
jsmeix commented at 2017-01-17 13:44:¶
Surprise!
As soon as one implements it correctly it even works correctly ;-)
RESCUE e205:~ # rear -d -D recover ... Using backup archive '/tmp/rear.vx3cRMiK2rq3Mjf/outputfs/rear/e205/20170117.1335/backup.tar.gz' ... Backup archive /tmp/rear.vx3cRMiK2rq3Mjf/outputfs/rear/e205/20170117.1311/backup.tar.gz detected. Backup archive /tmp/rear.vx3cRMiK2rq3Mjf/outputfs/rear/e205/20170117.1324/backup.tar.gz detected. Backup archive /tmp/rear.vx3cRMiK2rq3Mjf/outputfs/rear/e205/20170117.1335/backup.tar.gz detected. Select a backup archive. 1) 20170117.1311 2) 20170117.1324 3) 20170117.1335 4) Abort #? 2 Using backup archive '/tmp/rear.vx3cRMiK2rq3Mjf/outputfs/rear/e205/20170117.1324/backup.tar.gz'. ... Restoring from '/tmp/rear.vx3cRMiK2rq3Mjf/outputfs/rear/e205/20170117.1324/backup.tar.gz'...
jsmeix commented at 2017-01-17 15:38:¶
I am currently testing if with my latest changes
when USB_SUFFIX is set that then backup on USB
still works in compliance with backup on NFS
so that in particular incremental backups on USB
still "just work" with my changes in this pull request.
I have now in local.conf
OUTPUT=USB USB_DEVICE=/dev/disk/by-label/REAR-000 USB_SUFFIX="my_incremental_backups" BACKUP=NETFS BACKUP_URL=usb:///dev/disk/by-label/REAR-000 BACKUP_TYPE=incremental FULLBACKUP_OUTDATED_DAYS=7 FULLBACKUPDAY=Wed
I did "rear mkrescue" and three times "rear mkbackuponly".
On my my REAR-000 medium that results
rear/e205/my_incremental_backups/kernel rear/e205/my_incremental_backups/rear-e205.log rear/e205/my_incremental_backups/syslinux.cfg rear/e205/my_incremental_backups/backup.log rear/e205/my_incremental_backups/initrd.cgz rear/e205/my_incremental_backups/2017-01-17-1429-F.tar.gz rear/e205/my_incremental_backups/2017-01-17-1434-I.tar.gz rear/e205/my_incremental_backups/2017-01-17-1440-I.tar.gz
Recovery "just works" for me (excerpts):
RESCUE e205:~ # rear -d -D recover ... For backup restore using 2017-01-17-1429-F.tar.gz 2017-01-17-1434-I.tar.gz 2017-01-17-1440-I.tar.gz ... Disk layout created. Restoring from '/tmp/rear.6jGIeESS8tsZxYs/outputfs/rear/e205/my_incremental_backups/2017-01-17-1429-F.tar.gz'... ... Restored 2533 MiB in 24 seconds [avg. 108098 KiB/sec] Restoring from '/tmp/rear.6jGIeESS8tsZxYs/outputfs/rear/e205/my_incremental_backups/2017-01-17-1434-I.tar.gz'... ... Restored 33 MiB in 3 seconds [avg. 11504 KiB/sec] Restoring from '/tmp/rear.6jGIeESS8tsZxYs/outputfs/rear/e205/my_incremental_backups/2017-01-17-1440-I.tar.gz'... ... Restored 34 MiB in 3 seconds [avg. 11641 KiB/sec]
Now I think I can merge it.
[Export of Github issue for rear/rear.]