Re: rdiff-backup and computer suspend

Eric Beversluis writes: > So my question concerns how suspend work on Ubuntu. I assume that the > computer doesn't suspend if a process like rdiff-backup is > running. Maybe that's wrong. But I've always thought the computer > wouldn't suspend as long as there was activity. And if the computer >

Re: cross-platform backup tool We have a new site, and we need help!

EricZolf writes: >>- Does it mean that rdiff is no longer on savannah.nongnu.org? > > We've stopped using actively savannah.nongnu.org since many years, > even before my time, it's just technology-wise rather outdated and > doesn't offer all the amenities we are used from GitHub. This said,

Re: cross-platform backup tool We have a new site, and we need help!

Eric Zolf writes: > as the subject says, we have a new site at https://rdiff-backup.net/! Thanks for the update. I am a sometimes user and sometimes maintainer of the pkgsrc package. A few questions: - Does this mean https://www.nongnu.org/rdiff-backup/ is no more? - Does it mean that

Re: cross-platform backup tool Unexpectedly Slow on Initial Backup

Eric Robinson writes: >> -Original Message- >> From: EricZolf >> Sent: Monday, February 7, 2022 11:39 AM >> To: rdiff-backup-users@nongnu.org; Eric Robinson >> >> Subject: Re: cross-platform backup tool Unexpectedly Slow on Initial Backup >> >> Can you send me your hardware that I do

Re: [rdiff-backup-users] rdiff-backup performance -- slow operation on initial backup?

"Derek Atkins" writes: > ... according to repeated netstat the socket buffers are GENERALLY 0,0. I > did see it get up to about 1000, at one point... OH, I take that back, > the SEND Queue value was just up to 243816 on the target system If it bursts and comes back, it's

Re: [rdiff-backup-users] rdiff-backup performance -- slow operation on initial backup?

"Derek Atkins" writes: >> I would up the send/receive socket buffers (because it's easy, not >> because I think that's the problem), and watch disk/cpu on both sides, >> and also run netstat to see if data is piling up in the transmit socket >> buffer. > > Do you mean within

Re: [rdiff-backup-users] rdiff-backup performance -- slow operation on initial backup?

Dominic Raferd writes: > It doesn't sound like rdiff-backup is the culprit here. You could try > hpn-ssh https://sourceforge.net/projects/hpnssh/ ? I would be very surprised if normal people have networks available that really need hpn-ssh, and 2 MB/s is not that fast.

Re: [rdiff-backup-users] Security issue?

Patrik Dufresne writes: >> In the last few years there have not been any updates, not even the >> usual security and portability nits. > In your last reply you are making reference to security issue. Can you be > more specific? [top-posting repaired] I'm not David,

Re: [rdiff-backup-users] Sol1 taking over rdiff-backup

What's the motivation for leaving FSF hosting and moving to corporate hosting? signature.asc Description: PGP signature ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/rdiff-backup-users

Re: [rdiff-backup-users] fuzzy match - moved/renamed

David writes: > Are there plans to implement fuzzy match or similar algorithms to > match files moved/renamed files? In the last few years there have not been any updates, not even the usual security and portability nits. > What I would like to suggest is: > in case of

Re: [rdiff-backup-users] python3 support

Patrik Dufresne writes: > With python2 support ending in 2020, I'm wondering if there are any effort > to support both python2 and python3. Given how much python2-only stuff there is, I really have to wonder if it bugfix support will happen by someone. > The last version

Re: [rdiff-backup-users] crash with false No space left on device' raised of class error

Leon Maurer leon.mau...@gmail.com writes: Howdy, I'm having trouble with rdiff-backup crashing. It claims there's No space left on device, which is patently false. The drive is a 2TB drive that's 66% free when rdiff-backup is running: leon@leon-MiniPC:/media/seagate$ df -h | grep seagate

Re: [rdiff-backup-users] rdiff-backup limit time range

Eric Gendron concep...@gmail.com writes: I would like to know 2 things... How to limit hours of the backup. I would like to limit backup operations between 23h30 and 6h00am to not slow down the daytime bandwidth. Can I just kill the process (cron job) at 6h00am ? You can, but the next

Re: [rdiff-backup-users] rdiff-backup limit time range

Eric Gendron concep...@gmail.com writes: So how to limit backup working time ? Limit the area being backed up. Or how to interrupt a working backup that will continue next night? rdiff-backup can't do this. So rsync the entire remote system to shadow tree, incrementally when you can,

[rdiff-backup-users] failure to regress, not enough space but there is

I have been doing rdiff-backup of a filesystem that's around 400 GB to external disks for about 2 years. As I got more bits, the free space on the 1T backup disk (which has other stuff) got small, perhaps around 100G. After a failed backup (due to me killing it, or something going wrong, but

Re: [rdiff-backup-users] Incremental, automated, remote, secure

I was worried more about corruption *on the system being backed up*, which would not be detected for a long time, and then you have bad bits and want to find old backups. ___ rdiff-backup-users mailing list at rdiff-backup-users@nongnu.org

Re: [rdiff-backup-users] Incremental, automated, remote, secure

Grant emailgr...@gmail.com writes: Basically run dump or something on the client, to a holding disk file on the server with the tape. I don't see any issue with temporary disk use. The point is that all the temp bits are written anew each time, not assumed to be the same based on

Re: [rdiff-backup-users] Incremental, automated, remote, secure

Dominic Raferd domi...@timedicer.co.uk writes: On 19/07/2013 17:12, Greg Troxel wrote: I was worried more about corruption *on the system being backed up*, which would not be detected for a long time, and then you have bad bits and want to find old backups. I see. As long as the rdiff

Re: [rdiff-backup-users] Incremental, automated, remote, secure

Grant emailgr...@gmail.com writes: rdiff-backup preserves metadata in separate files so it doesn't need to be root on the storage node. If you can make that work, you can avoid the rsync-to-root and use an rdiff-backup-specific non-root user. I've been informed on this list before that

Re: [rdiff-backup-users] Incremental, automated, remote, secure

well, I mean somehow make a fresh copy from client to tape, such that you aren't relying on intermediate nodes having reliable state from the past. This is basically the old-school backup philosophy. ___ rdiff-backup-users mailing list at

Re: [rdiff-backup-users] Incremental, automated, remote, secure

Basically run dump or something on the client, to a holding disk file on the server with the tape. I don't see any issue with temporary disk use. The point is that all the temp bits are written anew each time, not assumed to be the same based on metadata. amanda is a system that works this

Re: [rdiff-backup-users] Incremental, automated, remote, secure

Edward Ned Harvey (rdiff-backup) rdiff-bac...@nedharvey.com writes: From: rdiff-backup-users-bounces+rdiff- backup=nedharvey@nongnu.org [mailto:rdiff-backup-users- bounces+rdiff-backup=nedharvey@nongnu.org] On Behalf Of Grant I'm struggling to devise an incremental, automated

Re: [rdiff-backup-users] How long should backup take

version 1.2.8 calls fsync ridiculously often. I found that on NetBSD with a journaling filesystem, fsync caused a flush of the log followed by a cache flush (which is reasonable, since fsync is supposed to guarantee that the bits are reliably on disk). This slowed it down so far as to be

Re: [rdiff-backup-users] SafeKeep version 1.4.0 (stable) released

Frank Crawford fr...@crawford.emu.id.au writes: I think you have a misconception about what SafeKeep is, it is a simplified interface to rdiff-backup, not a replacement. It simplifies such tasks as key deployment, snapshotting (yes, even if bound to a particular volume manager) and just

[rdiff-backup-users] excessive fsync(2)

With 1.2.8 on NetBSD, I was seeing insanely long backup times, as in over a week for a 300G filesystem on which little had changed. With ktrace, I found the problem was that fsync() was called incredibly often (per file checked?) and my backup drive was mounted with WAPBL (metadata journaling),

[rdiff-backup-users] 1.2.8 vs 1.3.3

On the web page, 1.2.8 is listed as stable and 1.3.3 as development/unstable. But, it's been a long time. So: are there changes since 1.3.3? if so, should there be a new release? is anyone who has project admin permission around? is 1.3.3 considered stable? As in, should I upgrade

Re: [rdiff-backup-users] Lost Connection

Try running tcpdump and seeing what happens, and check /var/log/messsages or equiv on both systems. Is the network between flaky or reliable? pgpNmrp55swZM.pgp Description: PGP signature ___ rdiff-backup-users mailing list at