#143 Issue closed: BACKUP_URL target should include/append backup date¶
Labels: enhancement, won't fix / can't fix / obsolete
cal-s opened issue at 2012-08-10 13:50:¶
Saving via nfs:// should probably append the creation date-time associated with the hostname, otherwise a subsequent mkbackup will overwrite the previous one. We export NFS dirs with root_squash, so it's not possible for root on the remote to create a dated subdirectory via its autofs paths in which to save to latest mkbackup. I seem to recall that this is done for USB-based mkbackups.
eg: local.conf:
BACKUP_URL=nfs://host/xfs/backup/rear
mkbackup will create t/xfs/backup/rear/host-fqdn
containing that host's ISO and tarbball
Preferably, ReaR should create the mkbackup in /xfs/backup/rear/host-fqdn/date or /xfs/backup/rear/host-fqdn-date
dagwieers commented at 2012-08-12 22:16:¶
Personally I agree.
The reason this was not done for the NFS use-case was that we did not want to break Relax-and-Recover for existing users, and because there is not retention-plan for the NFS use-case implemented. It is not impossible to do this, at some point in the future but we have to be very careful if we do this. And there needs to be consensus which there wasn't when we implemented the USB use-case.
cal-s commented at 2012-08-13 10:28:¶
Interesting, i'd sure like to hear the case against dated NFS retention, but let me guess:
I can work around it, but ...
Is there a procedure for getting a vote (or some alternate rationale) on this?
cheers
dagwieers commented at 2012-08-28 21:59:¶
No procedure (yet). But maybe we should list all the possible options we have together with the consequences, and do a vote.
cal-s commented at 2012-09-05 16:29:¶
Variable set in local.conf: APPEND_DATE?
gdha commented at 2014-03-03 07:40:¶
@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
# NETFS_KEEP_OLD_BACKUP_COPY may not be used in combination with BACKUP_TYPE=incremental!!!!
#NETFS_KEEP_OLD_BACKUP_COPY=y
BACKUP_TYPE=incremental
FULLBACKUPDAY="Mon"
It uses dates in its filenames. I guess this is more or less a solution to your problem?
bbeaver commented at 2014-06-04 17:23:¶
I'm testing with rear 1.16 and have not had any luck with incrementals. I'm using the config gdha recommends immediately above this post. 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 2015-09-23 11:34:¶
no time to work on this - sorry
[Export of Github issue for rear/rear.]