#421 Issue closed: Incremental backup options with rear¶
Labels: support / question, fixed / solved / done
bbeaver opened issue at 2014-06-04 17:37:¶
I'm testing with rear 1.16 and have not had any luck with incrementals. I'm using the following config:
@cal-s with rear it is now possible to make incremental and full
backups:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL=nfs://lnx01/vol/lnx01/linux_images_dr/rear
BACKUP_TYPE=incremental
FULLBACKUPDAY="Mon"
I've run "rear mkbackuponly" three times in a row, modifying a few files in between so I can check to see if only the incremental changes get picked up. What appears to happen instead, is rear creates what appears to be a full backup each time:
-rw-r--r--. 1 root root 2016177806 Jun 4 12:49
2014-06-04-1243-F.tar.gz
-rw-r--r--. 1 root root 2014242030 Jun 4 12:59
2014-06-04-1253-I.tar.gz
-rw-r--r--. 1 root root 2015048301 Jun 4 13:11 2014-06-04-1305-I.tar.gz
When I run the rear recover process, the first saved file is what gets restored, (2014-06-04-1243-F.tar.gz). Should I be prompted during the recovery process so that I can tell rear which bkup/incremental I want applied? Thanks for your help - great program, I've just got to figure incrementals out.
gdha commented at 2014-06-05 06:26:¶
See also issue #399 - the incremental tar was an user donation and is not yet fully working as it should
bbeaver commented at 2014-06-05 12:20:¶
Ok - thank you for your quick response.
gdha commented at 2014-06-20 11:20:¶
@bbeaver I think the problem has been fixed in the meantime by issue
#422
Can you check and give me some feedback? You can download the latest rpm
(dated 20140619* from OBS
(http://download.opensuse.org/repositories/Archiving:/Backup:/Rear:/Snapshot/)
bbeaver commented at 2014-06-20 17:27:¶
I've downloaded the latest rpm as suggested above and run the same tests again. I've run "rear mkbackuponly" three times in a row, modifying data between each run such that an incremental should have work to do. The outcome - I get a full gzip'd tarfile on my NFS server every time I run "rear mkbackuponly", (2014-06-20-1314-F.tar.gz). With this newer version, the files are named with the "F" each time, suggesting full. So, still not getting incremental bkups. How would rear know how to generate an incremental bkup based on a previous full gzip'd tarfile? Seems it would have to keep track of checksums somewhere, or use logic similar to what rsync uses. Here are the relevant local.conf variables I am using:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.10.10.10/NFS/"
BACKUP_TYPE=incremental
NETFS_KEEP_OLD_BACKUP_COPY=yes
Thanks
gdha commented at 2014-06-25 12:00:¶
@bbeaver Try adding FULLBACKUPDAY="Mon" to the local.conf file (it
will help)
bbeaver commented at 2014-07-28 17:58:¶
Sorry for the delay, just getting back to this. I've run a backup on a
client with hostname localhost using the following options:
OUTPUT=ISO
BACKUP=NETFS
BACKUP_URL="nfs://10.10.10.10/NFS/"
BACKUP_TYPE=incremental
NETFS_KEEP_OLD_BACKUP_COPY=yes
FULLBACKUPDAY="Mon"
This created the following files successfully on my NFS server:
-rw-------. 1 root root 61659136 Jul 28 13:52 rear-localhost.iso
-rw-------. 1 root root 304 Jul 28 13:52 VERSION
-rw-------. 1 root root 202 Jul 28 13:52 README
-rw-------. 1 root root 169158 Jul 28 13:52 rear.log
-rw-------. 1 root root 2239630504 Jul 28 14:02
2014-07-28-1347-F.tar.gz
-rw-------. 1 root root 13383371 Jul 28 14:03 backup.log
I will attempt another backup tomorrow, (Tuesday), and see if it generates an incremental.
Thanks
bbeaver commented at 2014-07-29 13:00:¶
Just ran another "rear -v mkbackup", and it did not produce an incremental backup.
NFS Server contents:
ls -lR
total 8
drwxr-x---. 2 root root 4096 Jul 29 09:00 localhost
drwxr-x---. 2 root root 4096 Jul 29 08:49 localhost.old
./localhost:
total 2312852
-rw-------. 1 root root 2292877209 Jul 29 09:00
2014-07-29-0843-F.tar.gz
-rw-------. 1 root root 13620162 Jul 29 09:00 backup.log
-rw-------. 1 root root 202 Jul 29 08:49 README
-rw-------. 1 root root 61667328 Jul 29 08:49 rear-localhost.iso
-rw-------. 1 root root 168947 Jul 29 08:49 rear.log
-rw-------. 1 root root 304 Jul 29 08:49 VERSION
./localhost.old:
total 2260616
-rw-------. 1 root root 2239630504 Jul 28 14:02
2014-07-28-1347-F.tar.gz
-rw-------. 1 root root 13383371 Jul 28 14:03 backup.log
-rw-r--r--. 1 root root 25 Jul 29 08:49 basebackup.txt
-rw-------. 1 root root 202 Jul 28 13:52 README
-rw-------. 1 root root 61659136 Jul 28 13:52 rear-localhost.iso
-rw-------. 1 root root 169158 Jul 28 13:52 rear.log
-rw-r--r--. 1 root root 11 Jul 29 08:49 timestamp.txt
-rw-------. 1 root root 304 Jul 28 13:52 VERSION
cat localhost.old/basebackup.txt
2014-07-29-0844-F.tar.gz
cat localhost.old/timestamp.txt
2014-07-29
I'll run another backup tomorrow, (Wednesday), and see if I get an incremental file produced.
Thanks
gdha commented at 2014-07-29 14:07:¶
Try with commenting NETFS_KEEP_OLD_BACKUP_COPY=yes in local.conf file.
That is the reason.
bbeaver commented at 2014-07-30 16:39:¶
Thanks - yes, this took care of it, and the backup is generating incremental files now. Next step is to confirm restores work properly begining with full through applying incrementals. REAR is a fantastic utility.
gdha commented at 2015-02-16 18:04:¶
added to the release notes so we can close this issue
[Export of Github issue for rear/rear.]