[rdiff-backup-users] Re: AW: Re: What happens if you add a --exclude to an existing rdiff-backup?

On 01/08/2011 05:17 AM, D. Kriesel wrote: It would be good if there was a way of removing a subset of data from the entire repository. So let's say I put a 500GB folder in /home by accident and it has gone into the repository and is bloating it. I can exclude it from my future rdiff-backup runs

[rdiff-backup-users] Re: Why using --force while restoring is dangerous?

On 02/09/2011 07:32 AM, Dominic Raferd wrote: My reading is that using --force on a restore will overwrite existing files with the same name - so you may lose previous data at the restore destination. In general if you are restoring a directory (or a complete repository) it is logical to use a

[rdiff-backup-users] Re: rdiff-backup --verify 1.2.8 running around in circles

On 02/20/2011 02:51 PM, Marc Haber wrote: On Sun, Feb 20, 2011 at 06:11:19PM +, Dominic Raferd wrote: Secondly, rdiff-backup --verify switch gives only a partial verification of the repository. Daniel Miller wrote a patch, available for rdiff-backup 1.2.8, which adds --verify-full and

[rdiff-backup-users] Re: rdiff-backup --verify 1.2.8 running around in circles

Sorry about the wrong link; http://lists.nongnu.org/archive/html/rdiff-backup-users/2010-02/msg00053.html -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete it. ___ rdiff-backup-users mailing list at

[rdiff-backup-users] Re: rdiff-backup --verify 1.2.8 running around in circles

On 02/21/2011 12:06 AM, Dominic Raferd wrote: On 21/02/11 00:22, Robert Nichols wrote: The patch file contains the following: +WARNING this will not detect if your repository has already been corrupted. +It will create integrity signatures with the files as they exist when you +run

[rdiff-backup-users] Re: Create Missing Data

On 03/18/2011 06:54 AM, MikeyG79 wrote: What you are missing is the manual page warning that you should never write to mirror directory except with rdiff-backup. Once you've corrupted the backup by making changes to the mirror, rdiff-backup won't function correctly for any files that you

[rdiff-backup-users] Re: Backup not identifying changed file, even though hash is different

On 03/23/2011 01:42 PM, Remy Blank wrote: Scott Jilek wrote: How does Rdiff identify changes that trigger backup? I know the file times/file size will not change since it's a fixed size 1GB container and Truecrypt purposely doesn't update file timestamps, but the hash will change as the

Re: [rdiff-backup-users] Linux to Windows file permissions

On 04/27/2011 04:06 AM, Jarno Veuger wrote: Hi everyone, I'm doing my first backup using rdiff-backup from Linux (CentOS5) to Windows Server 2003 (Pull from Windows). I was wondering, are the Linux file permissions backupped too? And what happens if I push the files back, are these

Re: [rdiff-backup-users] Cron and Rdiff-backup

On 05/25/2011 06:32 PM, Dan Nugent wrote: I am trying to use rdiff-backup from cron on an Ubuntu 10.04 server. I have a script with this rdiff-backup /home/dan/data /media/sdb1/data rdiff-backup /home/dan/data2 /media/sda1/data crontab looks like this: * 21 * * * sh

Re: [rdiff-backup-users] Is there an easy way to discard the most recent backup?

On 06/08/2011 02:24 PM, Ryan J wrote: Hi, To make a long story short, I accidentally ran rdiff-backup against a blank directory. Now my remote system has a blank mirror and the 1D old increment contains the most recent copy of my data. I'd like to restore from 1D ago rather than re-uploading

Re: [rdiff-backup-users] file-by-file changes from one backup to the next

On 06/14/2011 09:08 AM, Henrik wrote: Hi there, I've just recently switched backup system from rsnapshot to rdiff-backup for a part of my data. Mostly because of the space saved when large files have small changes, and thus the ability to retain more backups (possibly going back all the way to

Re: [rdiff-backup-users] rdiff-backup changes .gz files

On 07/17/2011 12:35 PM, Arno Wagner wrote: Hi, I found a bit more time and found also some .pm files with the same issue. Looking into the files though, I have a suspicion, namely that for some reason these files were changed by a Debian update, that then did set the same original metadata

Re: [rdiff-backup-users] rdiff-backup changes .gz files

skipped. Maybe we could check how rsync handles these cases? Maybe we could also store check inode number, but that wouldn't catch in-place modifications followed by metadata resets. On Sun, 17 Jul 2011, Robert Nichols wrote: All that matters is that rdiff-backup records a checksum

Re: [rdiff-backup-users] About backups and increments

On 08/21/2011 05:27 PM, Yuri D'Elia wrote: Is the backup procedure crash/interrupt safe? If I'm backing-up some data and for some reason the program gets killed (say, manually), in what state the backup will remain? Does the latest snapshot reflect the old state (as if no backup was performed),

Re: [rdiff-backup-users] About backups and increments

On 08/22/2011 10:54 AM, Robert Nichols wrote: print substr(bdate[1Dmax], 12, 10) Ouch! That should be 1+Dmax. Somehow the + sign got lost when I was reformatting the lines. -- Bob Nichols NOSPAM is really part of my email address. Do NOT delete

Re: [rdiff-backup-users] About backups and increments

On 08/22/2011 11:19 AM, Yuri D'Elia wrote: On Mon, 22 Aug 2011 10:54:48 -0500 Robert Nicholsrnicholsnos...@comcast.net wrote: Recovery from a failed or interrupted session is reliable, but time consuming. The next time you try to do any operation on that archive, rdiff-backup will insist on

Re: [rdiff-backup-users] About backups and increments

On 08/22/2011 02:26 PM, Maarten Bezemer wrote: Likewise, if a file hasn't been changed for 3 months and it is changed today, but I only want to keep 1 month of history, I can NOT simply ditch the 3-months old version. Maybe it wasn't changed for all these months, but it is still yesterday's

Re: [rdiff-backup-users] Changing ownership of files in archive

On 10/23/2011 03:51 PM, zero wrote: In the manual for rdiff-backup it says that one shouldn't change data in a backup archive, because this will make it impossible to get back old (changed files). But what about changing metadata? What will happen if I change the owner of all files in an

Re: [rdiff-backup-users] Changing ownership of files in archive

On 10/24/2011 02:47 PM, zero wrote: Robert Nichols wrote: Can't this be handled with the --user-mapping-file and --group-mapping-file options described in the USERS AND GROUPS section of the manual? If not, it would help if you would describe what you have tried and what the result or specific

Re: [rdiff-backup-users] user needs assistance in restoring directory

On 01/02/2012 11:57 PM, Shane Bywater wrote: Hi, I'm having a strange issue when trying to restore a directory. I'm using rdiff-backup 1.2.8 on both the local (backup) server where the backup is initiated and the data is saved to and the remote fileserver. The command I have been using to make

Re: [rdiff-backup-users] Any Thoughts on Why rdiff-backup Is So Slow?

On 03/13/2012 03:25 PM, Robinson, Eric wrote: Using rsync to copy a local directory to a remote computer takes a 67 seconds. Using rdiff-backup to backup the same local directory to a remote computer takes 11 minutes. Why does rdiff-backup go so slow? Does the number of increments on the remote

Re: [rdiff-backup-users] preserve-numerical-ids not working as expected

On 04/30/2012 08:28 AM, Jernej Simončič wrote: On Monday, April 30, 2012, 15:23:11, explosive wrote: Any ideas what I may be doing wrong? Only root can change ownership AFAIK. Correct. Nothing can change the ownership of the files in the repository unless the server is running with root

Re: [rdiff-backup-users] Filename with special character

On 06/04/2012 04:41 PM, m...@electronico.nc wrote: Here is an example: rdiff-backup --exclude /media/guillaume/archives/$RECYCLE.BIN /media/guillaume/archives /home/serveur/backup/guillaume/archives With that syntax, the shell will expand the $RECYCLE variable, and, since there is probably

Re: [rdiff-backup-users] rdiff-backup file consistency

On 06/06/2012 02:10 AM, Florian Kaiser wrote: The creators were aware of this and build in a verify-at TIME option. Using this after each backup will make a test-restore of every file up to the given timestamp and thus verify each increment, giving you the guarantee that you will be able to

Re: [rdiff-backup-users] rdiff-backup file consistency

On 06/06/2012 09:10 AM, Florian Kaiser wrote: That said, I understand the only way to actually verify all increments is to subsequently call verify-at TIME for all given TIMES you have increments for. Is that correct? It does not really sound thought-through and I guess it is a very time

Re: [rdiff-backup-users] rdiff-backup detects that many files has changed - cifs mount

On 07/26/2012 10:59 AM, Attila Strba wrote: Hi Bob, Thanks for the response. It happens every time. I have disabled SELinux, still the situation didn't improve. Is there a way I could analyse why rdiff thinks the files are different (like the security context)? The only thing I can think of

Re: [rdiff-backup-users] instrument data backup

On 07/29/2012 06:58 PM, Z F wrote: Basically, I need an easy access to files which are deleted from the system. The files which are present on the system at the backup time and were deleted before a subsequent backup can be easily found (using find) and restored with a cp command. Files which

Re: [rdiff-backup-users] Exception '[Errno 112] Host is down: along with --exclude-other-filesystems

On 08/23/2012 04:03 PM, Gregor Zattler wrote: Hi Robert, * Robert Nicholsrnicholsnos...@comcast.net [23. Aug. 2012]: Doing the exclude by name should avoid the problem. Simply excluding /mnt/* might suffice, since basically anything under /mnt should be a different file system. Ah. I

Re: [rdiff-backup-users] rdiff-backup logging in through sshd several times

On 09/05/2012 07:33 AM, weloki wrote: weloki wrote: I've been receiving logwatch reports each day from my servers and I notice after each backup that rdiff-backup connected via SSH many times, like from over 100 to 300 times per backup session. Why is this? Does it need to do that in order to

Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't

On 11/16/2012 04:21 AM, matthieu.riot...@skf.com wrote: Consider I already have 2 backups done on a daily basis (let me call them A and B chronologically -- thus B is the current mirror). I run 'rdiff-backup --compare' just before backing up : it returns no changes I run the back up and here

Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't

On 11/19/2012 02:50 AM, matthieu.riot...@skf.com wrote: I've got some more clues after this weekend. Of course, nobody has connected to the machine (i.e. open a session) during the weekend. But on each evening when backup was running, the complete (on almost complete) /home/ folder of one (and

Re: [rdiff-backup-users] Weird behavior of rdiff-backup : founding diffs while there isn't

On 11/21/2012 03:26 AM, matthieu.riot...@skf.com wrote: From: rnicholsnos...@comcast.net As I said, I have doubts about whether that will help. The names are still recorded in the mirror_metadata file even when --preserve-numerical-ids is used. On my side I think is that it could work. Even

Re: [rdiff-backup-users] File ownership on a portable drive

On 12/03/2012 12:29 AM, Grant wrote: For a long time I had rdiff-backup push backups to an external hard disk attached to my desktop. I moved and put the desktop in storage and now I'm putting the backup system back together with my laptop taking the place of the desktop. I noticed that

Re: [rdiff-backup-users] moving backup dir to external server produce errors

On 12/02/2012 04:34 PM, m...@electronico.nc wrote: Hi all, I had a rdiff-backup (1.2.8) that was setup to backup files locally (on the same server). I ran out of space on this server so I have copied via scp the backup directory to another server like this : [SNIPPED] Please don't hijack

Re: [rdiff-backup-users] File ownership on a portable drive

On 12/03/2012 01:47 PM, Grant wrote: All the owner and group IDs (both the names and the numeric IDs) are kept in the mirror_metadata files. By default, rdiff-backup will try to restore to the same owner and group _names_. You can use the --preserve-numerical-ids option to restore to

Re: [rdiff-backup-users] File ownership on a portable drive

On 12/04/2012 05:44 PM, Grant wrote: All the owner and group IDs (both the names and the numeric IDs) are kept in the mirror_metadata files. By default, rdiff-backup will try to restore to the same owner and group _names_. You can use the --preserve-numerical-ids option to restore

Re: [rdiff-backup-users] find old deleted directory

On 02/16/2013 07:45 PM, Eric Beversluis wrote: I tried: rdiff-backup --list-at-time 2012-12-31 /run/media/eric/b*/Fedora15-2Backup/var/www/html/jQuery but this gave me this reply: Fatal Error: Bad directory /run/media/eric/b*/Fedora15-2Backup/var/www/html/jQuery. It doesn't appear to be an

Re: [rdiff-backup-users] will this work?

On 03/28/2013 04:07 PM, Eugene Johnson wrote: I have ~3TB of files on 2 different qnap nas boxes. These server have a lot of small files if that matters. One is on the local network and the other is offsite. I would like to use rdiff-backup to backup my files to a removable sata drive in a

Re: [rdiff-backup-users] ACLs

On 07/21/2013 02:07 PM, Grant wrote: Just note (from http://www.nongnu.org/rdiff-backup/features.html): ACL and EA support: If rdiff-backup can find the pylibacl and pyxattr (mac version) modules, and if the file system supports these features, rdiff-backup will preserve Access Control Lists

Re: [rdiff-backup-users] Delay between EndTime and process end - followup

On 08/12/2013 07:09 AM, Laurent De Buyst wrote: 2013/08/12 06:00:56 Mon Aug 12 05:56:03 2013 Copying inc attrs from ... to ... 2013/08/12 06:00:56 Mon Aug 12 05:56:03 2013 Setting time of ... to 1376107515 2013/08/12 06:00:56 Mon Aug 12 05:57:36 2013 Renaming ... to

Re: [rdiff-backup-users] backing up a Bitcoin wallet (private key)

On 12/13/2013 12:50 AM, Gavin wrote: The LUKS file system needs a very long password to mount (which can be changed at any time). Keep in mind that anyone who has had access to the device holding the LUKS container has had an opportunity to make a copy of the LUKS header, thus making your

Re: [rdiff-backup-users] rdiff-backup should have MUCH simpler defaults

On 02/19/2014 06:28 PM, sunfun wrote: Am i missing somenthing, or do i have to go through a restore process to to even take a peek at the text in two versions of a text file? There is a FUSE tool rdiff-backup-fs that mounts the backup directory as a virtual filesystem and hides the restore

Re: [rdiff-backup-users] remove a single backup from increments

On 03/08/2014 02:55 AM, Marcus Schopen wrote: Hi, how do I remove a single backup run from increments, eg. the one at Sat Mar 8 07:02:51 2014: # rdiff-backup -l . Found 5 increments: increments.2014-03-04T18:18:57+01:00.dir Tue Mar 4 18:18:57 2014

Re: [rdiff-backup-users] cannot directly recover file but enclosing folder

On 03/15/2014 01:53 AM, Nicolas Jungers wrote: Yesterday I discovered that the user cannot recover a deleted file any more. But the user can recover the directory two levels above and from there extract the desired file. That seems quite odd to me and I wonder what can lead to that situation? I

Re: [rdiff-backup-users] Warning: Attempt to rename over same inode

On 04/02/2014 05:49 AM, Dominic Raferd wrote: On 29/03/2014 12:40, Marcus Schopen wrote: Hi, I got these warnings today, when running an rdiff-backup on some of my cyrus mailboxes. I did a lvm snap before running backup: Warning: Attempt to rename over same inode:

Re: [rdiff-backup-users] librsync 1.0.0 incompatible with rdiff-backup

On 03/28/2015 11:43 AM, Leszek Matok wrote: Hi, librsync 1.0.0 just landed on my Fedora 21 which: - breaks my existing rdiff-backup (it's librsync.so.2 now) - breaks building of rdiff-backup. The EPEL repo has released an updated rdiff-backup for that. You could grab the SRPM from there and

Re: [rdiff-backup-users] Why do I see a huge variation in the time rdiff-backup takes?

On 03/30/2015 06:41 PM, Segundo Bob wrote: I run rdiff-backup on my desktop computer to backup data from my internal hard drive to a removable internal hard drive. I use a script to do the backup every Sunday. Unpredictably, infrequently rdiff-backup runs much, much longer than usual. Why?

[rdiff-backup-users] Updated temp file does not match source -- Strange cause

UpdateError {pathname} Updated mirror temp file {pathname} does not match source No, the file is not changing. No, nothing is running out of space. I see this happening consistently for files with more than one hard link, and only under very specific conditions: 1. The archive's file system

Re: [rdiff-backup-users] Why do I see a huge variation in the time rdiff-backup takes?

On 03/31/2015 05:42 PM, Adrian Klaver wrote: http://www.nongnu.org/rdiff-backup/rdiff-backup.1.html --preserve-numerical-ids If set, rdiff-backup will preserve uids/gids instead of trying to preserve unames and gnames. See the USERS AND GROUPS section

Re: [rdiff-backup-users] Change to librsync

On 02/21/2015 09:05 PM, Frank Crawford wrote: Folks, By the looks of it, the following security change to librsync will have some effect on rdiff-backup: Changes in librsync 1.0.0 (2015-01-23) * SECURITY: CVE-2014-8242: librsync previously used a truncated MD4 strong check sum to match

Re: [rdiff-backup-users] Examples for whole-system backup

On 04/09/2015 01:41 AM, Nicolas Jungers wrote: I'm sure that you could devise some scheme to do a full metal restore with rdiff-backup, but in my opinion, it's not the tool for the job. If you back up the whole system, you get to restore the whole system. It's not an automated one-click

Re: [rdiff-backup-users] Updated temp file does not match source -- Strange cause

On 03/30/2015 09:58 PM, Robert Nichols wrote: UpdateError {pathname} Updated mirror temp file {pathname} does not match source No, the file is not changing. No, nothing is running out of space. I see this happening consistently for files with more than one hard link, and only under very

Re: [rdiff-backup-users] exclude, use of *

On 05/31/2015 03:13 AM, peter wrote: rdiff-backup -v5 --print-statistics --exclude-filelist rdiff-excludes /home/julius/ $host::${backup_folder} rdiff-excludes: - /home/julius/.cache - /home/julius/.local - /home/julius/tmp - /home/julius/Downloads -

Re: [rdiff-backup-users] Network performance

On 05/21/2015 09:50 AM, Laurent De Buyst wrote: Hello, I was wondering, if I run rdiff-backup and point it to a remote server, how much work gets done by that remote server? Or to be a bit more specific: would there be a serious difference in performance between: A) rdiff-backup to a remote

Re: [rdiff-backup-users] State of the rdiff-backup project

On 08/15/2015 05:17 AM, Frank Crawford wrote: However, these days, hard links are not that common, as most people prefer symbolic links. You might want to look in the directory trees under /usr/share/zoneinfo and /var/lib/yum/yumdb and reconsider that statement. Files in that latter tree can

Re: [rdiff-backup-users] Exception '[Errno 28] No space left on device'

On 07/22/2015 12:53 AM, Stephen Butler wrote: Perhaps this is an inode problem ? I just tried regressing a file, and i got another error 28 no space left on disk However the disk has 288gb space free Did a little googling and found suggestions that inodes can cause a problem if there are lots

Re: [rdiff-backup-users] restore from backup: can files be deleted again, which didn't exist back in time?

On 10/09/2015 04:47 AM, Marco Moller wrote: 1) Will rdiff-backup recognize that a meanwhile present file wasn't present back in time and thus delete the meanwhile present file, so that the restore does not just merge the files from the backup with the present files? rdiff-backup never merges.

Re: [rdiff-backup-users] Repair repository

On 09/14/2015 06:46 PM, Patrik Dufresne wrote: One of my backup repository seams to be mess up alot. I think the backup have been interrupted multiple time. I do have a very long history for this backup and I don't want to lose it. First, I encounter "regressing destination" error. So as usual,

Re: [rdiff-backup-users] How does rdiff-backup really detect changed files?

On 04/10/2016 09:15 AM, David Croll wrote: Dear wizards of rdiff-backup, as a user of rdiff-backup and main author of the German Wikipedia page on rdiff-backup I want to ask you a few questions because the manual pages are not very clear on this: - Is SHA-1 always used to determine if a file

Re: [rdiff-backup-users] Restore while backing up

On 07/11/2016 07:06 AM, Laurent De Buyst wrote: "Fatal Error: It appears that a previous rdiff-backup session with process id 17597 is still running. If two different rdiff-backup processes write the same repository simultaneously, data corruption will probably result. To proceed with regress

[rdiff-backup-users] Hard link issues (was: Incredibly slow i/o to NAS server)

On 12/05/2016 03:26 PM, Robert Nichols wrote: On 12/05/2016 09:28 AM, Joe Steele wrote: I believe the harlink problems you describe are identified in this bug report (that I submitted in 2009): http://savannah.nongnu.org/bugs/?func=detailitem_id=26848 Attached to the report are patches

Re: [rdiff-backup-users] Merge old backup stages

On 09/12/2016 11:01 AM, bb wrote: Hello! This is the first time I read and refer to this mailing list, so if this is an old topic for you... sorry :-) I use rdiff-backup as my main backup tool in private (Laptop), public (Server) and profession and love it. One thing I always wondered, though,

Re: [rdiff-backup-users] New System Chown Backup-Hard-drive for new user?

On 10/08/2016 10:23 AM, Wayne Sallee wrote: I created a new linux opperating system. While I used the same user name, the number is different, so I copied my stuff over to the new system, and chowned the files over. No problem there. But now I need to get back to doing the rdiff-backups to

Re: [rdiff-backup-users] Incredibly slow i/o to NAS server

On 12/03/2016 09:32 PM, Andrea Bolandrina wrote: Bob - yes, lots of files under /mnt/vms/docker/ have more than one hard link. I might try your suggestion (--no-compare-inode) if I run into trouble again. What problems does rdiff-backup have with hard linked content? As far as I know hard links

Re: [rdiff-backup-users] Incredibly slow i/o to NAS server

On 12/05/2016 09:28 AM, Joe Steele wrote: On 12/4/2016 9:58 AM, Robert Nichols wrote: On 12/03/2016 09:32 PM, Andrea Bolandrina wrote: What problems does rdiff-backup have with hard linked content? As far as I know hard links should be supported... Supported? Yes, but with plenty of bugs

Re: [rdiff-backup-users] Incredibly slow i/o to NAS server

On 12/05/2016 04:01 AM, Frank Crawford wrote: On Sun, 2016-12-04 at 08:58 -0600, Robert Nichols wrote: I really want to look into SafeKeep <http://safekeep.sourceforge.net/> as an alternative, but I haven't had a chance to do that. However, SafeKeep uses rdiff-backup under the

Re: [rdiff-backup-users] Incredibly slow i/o to NAS server

On 12/05/2016 09:13 AM, Patrik Dufresne wrote: On Mon, Dec 5, 2016 at 10:02 AM, Robert Nichols <rnicholsnos...@comcast.net <mailto:rnicholsnos...@comcast.net>> wrote: On 12/05/2016 04:01 AM, Frank Crawford wrote: On Sun, 2016-12-04 at 08:58 -0600, Robert N

Re: [rdiff-backup-users] [bug] Excluding hidden files the wrong way doesn't result in an error

On 01/04/2017 01:00 PM, Ilario wrote: Excluding a hidden file without full path doesn't rise an error (as happens with non hidden files) and copies it anyway; e.g. mkdir temp cd temp mkdir .one mkdir .two mkdir three mkdir four rdiff-backup --exclude .one --exclude ./.two --exclude ./three .

Re: [rdiff-backup-users] Still maintained?

On 02/05/2018 12:25 PM, Mr. Clif wrote: +1 at home and production servers. Also wrote this: https://eugenemakerspace.com/wiki/Sites/Rdiff-backup-delete would be nice if that functionality could be folded back in to Rdiff-backup. :-)     Clif Cox I wrote a script that does that too. Calling

Re: [rdiff-backup-users] Python 3 migration: considering non-UTF-8 conform filenames

On 8/3/19 6:49 AM, Patrik Dufresne wrote: Hello Éric, im very concerned about this. I did not review all your changes, and did not notice this fact. I'm backup allot of various system and the encoding are not all utf8. And invalid utf8 happen quite often. The way to work around this in rdiffweb

Re: [rdiff-backup-users] --check-destination-dir taking a very long time

On 9/12/19 7:55 AM, Patrik Dufresne wrote: For a server, I would recommend ZFS without hesitation. Data integrity is at the heart of ZFS which makes it a very good choice for backup storage. It provides many features that ease the storage management. Quota, compression, configurable record size,

Re: Problems with backup after using rdiff-backup-delete.py

On 11/29/19 1:10 PM, Patrik Dufresne wrote: Hi Robert Nichols, Your contribution is welcome. There is a folder with user's contribution in rdiff-backup repositories. We could probably leave it their with some user warning. So either submit a Pull Request in github or send it here as attachment

Re: Problems with backup after using rdiff-backup-delete.py

On 11/29/19 11:00 AM, Brian Gupta wrote: So I work with OP, and am trying to sort out our path forward. We have been using rdiff-backup for over 7 years, and we generally keep backups indefinitely. A few years ago or so, we had to remove certain PII data from our backups, for contractual

Re: using --remove-older-than takes a very long time?

On 2/7/20 11:42 AM, Derek Atkins wrote: Hi, On Fri, February 7, 2020 12:31 pm, Eric L. wrote: A profiling as such is possible at python level but I would start with just calling the removal option with `-v9`, it should give you/us a first hint as the date/times for each action are logged. I

Re: Trying to install beta in CentOS 8 -- missing py3libacl, python3-pyxattr

On 1/11/20 3:00 PM, Robert Nichols wrote: I am far, far away from getting this to install. "pip3 install pyxattr" fails with:    acl.c:23:10: fatal error: Python.h: No such file or directory All attempts to install rdiff-backup fail with:    No matching distribution found for rd

Re: Trying to install beta in CentOS 8 -- missing py3libacl, python3-pyxattr

] describes how to install the wheel. @Frank the dependencies py3libacl and python3-pyxattr of the RPM should only be recommendations IMHO Hope this helps, Eric [1] https://github.com/rdiff-backup/rdiff-backup#on-linux On January 6, 2020 4:26:40 AM UTC, Robert Nichols wrote: Looks like I'll

Re: Trying to install beta in CentOS 8 -- missing py3libacl, python3-pyxattr

On 1/11/20 5:16 PM, Robert Nichols wrote: On 1/11/20 4:03 PM, Robert Nichols wrote: On 1/11/20 3:00 PM, Robert Nichols wrote: I am far, far away from getting this to install. "pip3 install pyxattr" fails with:     acl.c:23:10: fatal error: Python.h: No such file or directory Al

Incorrect NumHardLinks counts for hard linked files

I'm finding the situation with hard linked files a lot better than I expected. The only problem I've run across is that when new files are added to an existing group of hard linked files, only the newly added files get the correct NumHardLinks count in the mirror_metadata file.

Re: Trying to install beta in CentOS 8 -- missing py3libacl, python3-pyxattr

On 1/5/20 5:00 PM, Marcin Zajączkowski wrote: CCing Dan which introduced python3-pyxattr in EPEL some time ago. On 2020-01-05 22:12, Robert Nichols wrote: Installing version 1.4.0b0-1-el8 from the frankcrawford COPR fails with missing dependencies py3libacl and python3-pyxattr. I'd really like

Trying to install beta in CentOS 8 -- missing py3libacl, python3-pyxattr

Installing version 1.4.0b0-1-el8 from the frankcrawford COPR fails with missing dependencies py3libacl and python3-pyxattr. I'd really like to do some testing before 2.0 is released. What should I install? Python version on CentOS 8 is 3.6.8. -- Bob Nichols "NOSPAM" is really part of my

Re: Version Woes

On 4/17/20 8:46 PM, Frank Crawford wrote: On Fri, 2020-04-17 at 08:27 -0500, Robert Nichols wrote: On 4/17/20 12:52 AM, ewl+rdiffbac...@lavar.de wrote: That's if you _can_ upgrade on both sides. I have CentOS 6 clients, and their Python 3 version is 3.4.10, which is too old for rdiff-backup

Re: Version Woes

On 4/17/20 12:52 AM, ewl+rdiffbac...@lavar.de wrote: Hi, and one last comment: the migration guide from Patrik is meant for big environments where you can't upgrade all rdiff-backup installations at once. If you have only one server and one client, you can just upgrade rdiff-backup on both

Re: corrupted metadata

On 9/6/20 1:42 PM, Marco Strullato wrote: Hi all, it's my turn, metadata got corrupted. From the log I see: "*Error: Warning, could not find mirror_metadata file. Metadata will be read from filesystem instead.*" I did follow the faq in the guide, but the trick is unsuccessful.

Re: corrupted metadata

On 9/7/20 10:47 AM, Marco Strullato wrote: Il giorno dom 6 set 2020 alle ore 23:07 Robert Nichols < rnicholsnos...@comcast.net> ha scritto: On 9/6/20 1:42 PM, Marco Strullato wrote: Hi all, it's my turn, metadata got corrupted. From the log I see: "*Error: Warning, cou

Re: Question around of remote description

On 6/17/20 1:15 AM, Eric L. Zolf wrote: Hi, in the course of the review of PR #404 we came to challenge the quite complex quoting rules allowed when you backup to/from a remote location. Our question is if anybody is relying on those (too) complex quoting rules to make their backup work? Else

Re: Discussion about file format for the future

On 6/5/20 4:44 PM, Arrigo Marchiori wrote: If we were going to substitute a lot of files with a single file (that is what a SQLite database is in the end, right?) then we may somehow introduce a "single point of failure" for the whole backup. The rdiff-backup archive structure is already a

Re: Discussion about file format for the future

On 6/9/20 9:44 AM, rhkra...@gmail.com wrote: In the case of rdiff-back, it wouldn't surprise me that diffs (deltas) are stored as forward deltas, and, in removing old deltas, a new "base" must be created before deleting the deltas. (My words probably aren't exactly correct, I hope they are

Re: Discussion about file format for the future

On 6/4/20 11:43 AM, Patrik Dufresne wrote: But two cent on the subject is, should we really keep this filebase ? For rdiffweb, scanning the metadata files is a nightmare. When I just need a subset of the data to be displayed to the user. I always thought a database could be better fit for the

Re: change timestamps of backups?

On 4/22/21 7:05 AM, Patrik Dufresne wrote: 4. Finally, if you want to force a particular timestamp to match your dump file numbering, you may enforce a date when running the backup. Take a look at `--current-time` This way you could mimic the fact the backup is running in the past or future

Re: win_acls changes trigger creation of increments

On 4/21/21 12:08 PM, Patrik Dufresne wrote: [snip] 1. I'm not aware of any changes in the logic between 1.2.8 and 2.0.5 regarding Win_acls. So I'm expecting this to be an issue in 2.0.5. Is it ? 2. Would we consider this normal behavior to create increments (empty increment) when the only

Re: cross-platform backup tool Same files from different source dir causes spurious diff files

On 2/7/22 7:23 PM, Leland Best wrote: Hi Cliff, On Mon, 2022-02-07 at 11:45 -0800, Mr. Clif wrote: Hey Eric, any ideas on this? How do these diff files normally work? [...] I'm not an 'rdiff-backup' developer or anything so all you experts out there correct me if I'm wrong but ... IIRC

Re: cross-platform backup tool Same files from different source dir causes spurious diff files

On 2/8/22 1:05 AM, Mr. Clif wrote: Hey folks, thanks for the feedback. :-) More comments below... On 2/7/22 8:25 PM, Robert Nichols wrote: On 2/7/22 7:23 PM, Leland Best wrote: Hi Cliff, On Mon, 2022-02-07 at 11:45 -0800, Mr. Clif wrote: Hey Eric, any ideas on this? How do these diff

Re: cross-platform backup tool Same files from different source dir causes spurious diff files

On 2/8/22 12:22 AM, Eric Lavarde wrote: Hi, even if it's not the inodes, it might be any kind of metadata (ownership, time, access rights, etc). I could for example imagine that the LVM snapshot is readonly, which would make rdiff-backup consider that there is a change, as Leland already

Re: cross-platform backup tool Same files from different source dir causes spurious diff files

On 2/8/22 6:44 PM, Mr. Clif wrote: ok cool, good info, I was just digging into it again, and the date I switched to the snapshot was recorded as Feb 1st. Here is a list of the mirror_metadata files leading up to that: -rw--- 1 root root 2.7M Jan 21 05:25

Re: cross-platform backup tool First beta v2.1.2b1 release towards v2.2.0

On 9/7/22 11:11 AM, EricZolf wrote: Hello everybody, This is a beta release so that many people can test before this becomes the next stable release. All changes are documented in the changelog . Check

Re: cross-platform backup tool incremental rdiff-backup takes long

On 10/18/22 1:37 AM, Jonas Schöpf wrote: I deleted a lot of stuff on my machine (around 200GB) and if I do a new backup I have to abort it after 9 hours as it does not finish. iostat -x -m 3 shows that %util is always between 70 and 95. So I assume that IO is again a bottleneck, but shouldn't

Re: cross-platform backup tool Survey about rdiff-backup-statistics

On 10/29/22 8:49 AM, EricZolf wrote: no plan to remove the data itself. Just to potentially get rid of the sub-command. Eric That's good. I do make use of the file_statistics data to detect "zero-diff" increment files. Prior to this survey, I had never tried running the

cross-platform backup tool Traceback of failed backup

Can someone please make sense of this traceback from a rdiff-backup 2.0.5 client backing up to a rdiff-backup 2.1.3b3 server. The directory /usr/lib/modules/5.19.12-200.fc36.x86_64/extra is deleted since the previous backup. The entire /usr/lib/modules/5.19.12-200.fc36.x86_64 subtree was

Re: cross-platform backup tool Traceback of failed backup

g an issue with the exact call you used? Thanks, Eric PS: Fedora, good distro choice :-) On 29/10/2022 17:28, Robert Nichols wrote: Can someone please make sense of this traceback from a rdiff-backup 2.0.5 client backing up to a rdiff-backup 2.1.3b3 server. The directory /usr/lib/modules/5.19.12-200.f

Re: cross-platform backup tool First beta v2.1.2b1 release towards v2.2.0

On 9/7/22 11:11 AM, EricZolf wrote: Hello everybody, This is a beta release so that many people can test before this becomes the next stable release. All changes are documented in the changelog . Check

  1   2   >