Comment

Comment on

tal@olio.cafe ⁨3⁩ ⁨weeks⁩ ago

I would generally argue that rsync is not a backup solution.

Yeah, if you want to use rsync, you’re probably better-off using something like rdiff-backup, which makes use of rsync to generate backups and store them efficiently.

rsync: one-way synchronization

unison: bidirectional synchronization

git: synchronization of text files with good interactive merging.

rdiff-backup: rsync-based backups. I used to use this and moved to restic, as the backupninja target for rdiff-backup has kind of fallen into disrepair.

source

Sort:hotnew top

melfie@lemy.lol ⁨3⁩ ⁨weeks⁩ ago
Having a synced copy elsewhere is not an adequate backup and snapshots are pretty important. I recently had RAM go bad and my most recent backups had corrupt data, but having previous snapshots saved the day.

source
- melfie@lemy.lol ⁨2⁩ ⁨weeks⁩ ago
  Don’t understand the downvotes. This is the type of lesson people have learned from losing data and no sense in learning it the hard way yourself.
  
  source
  - tomenzgg@midwest.social ⁨2⁩ ⁨weeks⁩ ago
    How would you pin down something like this? If it happened to me, I expect I just wouldn’t understand what’s going on.
    
    source
    melfie@lemy.lol ⁨2⁩ ⁨weeks⁩ ago
    I originally thought it was one of my drives in my RAID0 array that was failing, but I noticed copying data was yielding btrfs corruption errors on both drives and I was also getting btrfs corruption errors on the root volume as well. I figured it would be quite an odd coincidence if my main SSD and 2 hard disks all went bad and I happened upon an article talking about how corrupt data can also occur if the RAM is bad. So, I installed and booted into Memtester86+ and it immediately started showing errors on the single 16Gi stick I was using. I happened to have a spare stick that was a different brand, and that one passed the memory test with flying colors. After that, all the corruption errors went away and everything has been working perfectly ever since.
    
    I will also say that another file system like ext4 wouldn’t even complain about corrupt data. I originally had ext4 on my main drive and at one point thought my OS install went bad, so I reinstalled with btrfs on top of LUKS and saw I was getting corruption errors on the main drive at that point, so it occurred to me that 3 different drives could not have possibly had a hardware failure and something else must be going on.
    
    source
koala@programming.dev ⁨3⁩ ⁨weeks⁩ ago
Beware rdiff-backup. It certainly does turn rsync (not a backup program) into a backup program.

However, I used rdiff-backup in the past and it can be a bit problematic. If I remember correctly, every “snapshot” you keep in rdiff-backup uses as many inodes as the thing you are backing up. (Because every “file” in the snapshot is either a file or a hard link to an identical version of that file in another snapshot.) So this can be a problem if you store many snapshots of many files.

But it does make rsync a backup solution; a snapshot or a redundant copy is very useful, but it’s not a backup.

(OTOH, rsync is still wonderful for large transfers.)

source
- tal@olio.cafe ⁨2⁩ ⁨weeks⁩ ago
  
  Because every “file” in the snapshot is either a file or a hard link to an identical version of that file in another snapshot.) So this can be a problem if you store many snapshots of many files.
  
  I think that you may be thinking of rsnapshot rather than rdiff-backup which has that behavior; both use rsync.
  
  But I’m not sure why you’d be concerned about this behavior.
  
  Are you worried about inode exhaustion on the destination filesystem?
  
  source
  - koala@programming.dev ⁨2⁩ ⁨weeks⁩ ago
    Huh, I think you’re right.
    
    Before discovering ZFS, my previous backup solution was rdiff-backup. I have memories of it being problematic for me, but I may be wrong in my remembering of why it caused problems.
    
    source
neidu3@sh.itjust.works ⁨3⁩ ⁨weeks⁩ ago
+1 for rfiff-backup. Been usinit for 20 years or so, and I love it.

source