Re: rsync: source and destination drive data used sizes differ

On Mon, Jan 20, 2025 at 00:08:54 +, David wrote: > I would have recognised this > echo a{1..5}b > as brace expansion, but I hadn't absorbed the extra glorious > capabilities of its commas. The commas were the original form. The .. range feature was added in bash version 3.0.

Re: rsync: source and destination drive data used sizes differ

On Sun, 19 Jan 2025 at 16:24, Greg Wooledge wrote: > On Sun, Jan 19, 2025 at 12:43:51 -0300, Eduardo M KALINOWSKI wrote: > > Em 19/01/2025 08:57, David escreveu: > > > On Sun, 19 Jan 2025 at 02:51, Default User > > > wrote: > > > > time sudo rsync -aHSxvvv --human-readable --delete --numeric-id

Re: rsync: source and destination drive data used sizes differ

On Sun, Jan 19, 2025 at 12:43:51 -0300, Eduardo M KALINOWSKI wrote: > Em 19/01/2025 08:57, David escreveu: > > On Sun, 19 Jan 2025 at 02:51, Default User > > wrote: > > > time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids -- > > > info=progress2,stats2,name2 -- > > > exclude={"/dev/

Re: rsync: source and destination drive data used sizes differ

Em 19/01/2025 08:57, David escreveu: On Sun, 19 Jan 2025 at 02:51, Default User wrote: time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids -- info=progress2,stats2,name2 -- exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media /*","/lost+found"} /media/user/DRIVE1

Re: rsync: source and destination drive data used sizes differ

On Sat, 18 Jan 2025 21:01:14 -0700 Charles Curley wrote: > I suggest that instead of using rsync directly you use rsnapshot. You > can set it up so that it only copies if DRIVE2 is there. The cron > entries let it happen automatically. Another advantage to rsnapshot is that you don't have to fid

Re: rsync: source and destination drive data used sizes differ

On Sun, 19 Jan 2025 at 02:51, Default User wrote: > I may just delete everything on DRIVE2 overnight, and then try rsync > with: > > time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids -- > info=progress2,stats2,name2 -- > exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/

Re: rsync: source and destination drive data used sizes differ

On 2025-01-19, e...@gmx.us wrote: > I've never used LUKS before, so we're even. With a non-encrypted > filesystem, you would > unmount the partition > mkfs -t whatever /dev/whatever > mount it again It's the same with luks and the device used is a mapping in /dev/mapper

Re: rsync: source and destination drive data used sizes differ

On Sat, Jan 18, 2025 at 08:27:17PM -0500, Default User wrote: > Hi! [...] > Every night, I have been using rsync to copy from DRIVE1 to DRIVE2, > doing: > > time sudo rsync -avvv --human-readable --delete --numeric-ids > --info=progress2,stats2,name2 -- > exclude={"/dev/*","/proc/*","/sys/*","/t

Re: rsync: source and destination drive data used sizes differ

On 1/18/25 22:21, Default User wrote: > Hi, Eben! > > I hate to sound stupid, but how would I do that. I have never used mkfs > before. I've never used LUKS before, so we're even. With a non-encrypted filesystem, you would unmount the partition mkfs -t whatever /dev/whatever mount it again

Re: rsync: source and destination drive data used sizes differ

On 1/18/25 17:27, Default User wrote: Hi! I have two identical 4Tb usb external drives, Western Digital Model WDC WD40NDZW-11A8JS1. My computer is a Dell Inspiron 15 3000 Model 3511 (a very modest laptop), from early 2024, running Debian 12 Stable, always kept updated. Thank you for that info

Re: rsync: source and destination drive data used sizes differ

Hi, Charles! Thanks for the reply. I will have to ponder that.

Re: rsync: source and destination drive data used sizes differ

On Sat, 18 Jan 2025 20:36:42 -0500 Default User wrote: > So, back to the original question: what in the world am I supposed to > do to have rsync copy so that the size change in the two drives is > equal, and DRIVE2 has (theoretically) the same data, taking up the > same space, as DRIVE1? I sugg

Re: rsync: source and destination drive data used sizes differ

Hi, Eben! I hate to sound stupid, but how would I do that. I have never used mkfs before.

Re: rsync: source and destination drive data used sizes differ

On 1/18/25 21:50, Default User wrote: > Hi Andy! > > Thanks for the reply. > > I may just delete everything on DRIVE2 overnight, Might be faster to mkfs than to rm *.

Re: rsync: source and destination drive data used sizes differ

Hi Andy! Thanks for the reply. I may just delete everything on DRIVE2 overnight, and then try rsync with: time sudo rsync -aHSxvvv --human-readable --delete --numeric-ids -- info=progress2,stats2,name2 -- exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media /*","/lost+found"}

Re: rsync: source and destination drive data used sizes differ

Hi Default, On Sat, Jan 18, 2025 at 08:36:42PM -0500, Default User wrote: > So, back to the original question: what in the world am I supposed to > do to have rsync copy so that the size change in the two drives is > equal, and DRIVE2 has (theoretically) the same data, taking up the same > space,

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Friday 09 February 2024 04:41:37 pm hw wrote: > On Fri, 2024-02-09 at 11:34 -0500, Roy J. Tellason, Sr. wrote: > > On Friday 09 February 2024 06:07:16 am hw wrote: > > > What other manufacturers could we buy UPSs from? > > > > I have a Tripp-Lite sitting next to me here that replaced an APC an

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

hw wrote: > On Fri, 2024-02-09 at 06:44 -0500, Dan Ritter wrote: > > hw wrote: > > > On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote: > > > > [...] > > > That sucks. I didn't know that they don't stand behind their > > > products, and it makes APC not recommendable any longer. > > > > > > W

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri, 2024-02-09 at 11:34 -0500, Roy J. Tellason, Sr. wrote: > On Friday 09 February 2024 06:07:16 am hw wrote: > > What other manufacturers could we buy UPSs from? > > I have a Tripp-Lite sitting next to me here that replaced an APC and > has 2-1/2 times the capabiliity. Been in service sever

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri, 2024-02-09 at 06:44 -0500, Dan Ritter wrote: > hw wrote: > > On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote: > > > [...] > > That sucks. I didn't know that they don't stand behind their > > products, and it makes APC not recommendable any longer. > > > > What other manufacturers cou

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

>> What other manufacturers could we buy UPSs from? > I have a Tripp-Lite sitting next to me here that replaced an APC and has > 2-1/2 times the capabiliity. Been in service several weeks and so far I'm > pretty happy with it... Would they accept a warranty claim without having to run some propri

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Friday 09 February 2024 06:07:16 am hw wrote: > What other manufacturers could we buy UPSs from? I have a Tripp-Lite sitting next to me here that replaced an APC and has 2-1/2 times the capabiliity. Been in service several weeks and so far I'm pretty happy with it... -- Member of the tou

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

hw wrote: > On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote: > > [...] > That sucks. I didn't know that they don't stand behind their > products, and it makes APC not recommendable any longer. > > What other manufacturers could we buy UPSs from? Liebert at the high end, CyberPower at the lo

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Thu, 2024-02-08 at 15:29 +, Andy Smith wrote: > [...] > Someone on the apcupsd mailing list thinks I have a faulty UPS or > battery and should get a replacement. > > APC refuses to proceed with a warranty claim because they don't > support apcupsd or nut, only their own proprietary Powerchu

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On 2024-02-08, Charles Curley wrote: > On Thu, 8 Feb 2024 15:29:21 + > Andy Smith wrote: > >> I do not overly want to buy a Windows licence, run it >> in a VM and pass USB through to that VM just to try this. > > You could try wine. You might need the more recent crossover-office, > which is

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Thu, 8 Feb 2024 15:29:21 + Andy Smith wrote: > I do not overly want to buy a Windows licence, run it > in a VM and pass USB through to that VM just to try this. You could try wine. You might need the more recent crossover-office, which is proprietary (but contributes greatly to wine). --

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

Hello, On Sun, Jan 28, 2024 at 06:55:04PM +, Andy Smith wrote: > So, I must admit, I am quite tempted by BX1600MI which would cost me > about £183. The equivalent spec in the Pro range is more than twice > this price. [ TL;DR: While free software like apcupsd or nut support all APC models t

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync--delete-after)

On 1/28/24 13:55, Andy Smith wrote: Hi, Thanks, this is very useful. On Sun, Jan 28, 2024 at 06:58:08PM +0100, hw wrote: However, stay away from their cheap models as seen on this[1] picture (Back UPS). They work and you can replace the batteries yourself even though you're not supposed to.

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

Hi, Thanks, this is very useful. On Sun, Jan 28, 2024 at 06:58:08PM +0100, hw wrote: > However, stay away from their cheap models as seen on this[1] picture > (Back UPS). They work and you can replace the batteries yourself even > though you're not supposed to. It's a minimum basic device. It

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri, 2024-01-26 at 15:17 +, Andy Smith wrote: > Hi, > > On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote: > > I've never had issues with any UPS due to self tests. The batteries > > need to be replaced when they are worn out. How often that is > > required depends on the UPS and the con

Re: rsync --delete vs rsync --delete-after

On Fri, 2024-01-26 at 16:27 +, Michael Kjörling wrote: > On 26 Jan 2024 16:39 +0100, from h...@adminart.net (hw): > [...] > > Having multiple generations of backups already increases the needed > > storage space by a bit more than half. That makes it already arguable > > if it's better to make

Re: rsync --delete vs rsync --delete-after

On Fri, 2024-01-26 at 16:11 +0100, hw wrote: > I've never had issues with any UPS due to self tests.  The batteries > need to be replaced when they are worn out.  How often that is > required depends on the UPS and the conditions it is working in, > usually every 3--5 years. It was with some small

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri, 26 Jan 2024, David Wright wrote: On Fri 26 Jan 2024 at 19:03:33 (+0100), Roger Price wrote: I currently have two Eaton Ellipse ECO 1600's. ... The four screws are deeply recessed and difficult to see. They have different heads: some are Torx 10, others are a star. 20/20 hindsight m

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri 26 Jan 2024 at 19:03:33 (+0100), Roger Price wrote: > I currently have two Eaton Ellipse ECO 1600's. I change the batteries > every 4-5 years, but this is not as easy as it should be. It is not > evident that only one of the four back panel screws needs to be > removed. I took me a while

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri, 26 Jan 2024, Andy Smith wrote: Out of interest what brand of UPS do you recommend for home use that has easily-replaceable batteries every 3–5 years? For a load of about 300W. I currently have two Eaton Ellipse ECO 1600's. I change the batteries every 4-5 years, but this is not as ea

Re: rsync --delete vs rsync --delete-after

On 26 Jan 2024 16:39 +0100, from h...@adminart.net (hw): >> RAID is for uptime. > > It's also for saving you from the hassle involved with loosing data > when a disk fails. Which translates to more quickly fully recovering from the loss of a storage device. When used for redundancy and staying w

Re: rsync --delete vs rsync --delete-after

On Thu, 2024-01-18 at 13:09 +, Michael Kjörling wrote: > On 18 Jan 2024 13:26 +0100, from r...@h5.or.at (Ralph Aichinger): > > As a home/SOHO user, I'd rather have a working backup every few hours > > or every day than some RAID10 wonder > > Definitely agree that a solid backup regimen (includ

Re: Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

On Fri, 26 Jan 2024, Andy Smith wrote: > Hi, > > On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote: >> I've never had issues with any UPS due to self tests. The batteries >> need to be replaced when they are worn out. How often that is >> required depends on the UPS and the conditions it is wor

Home UPS recommendations (Was Re: rsync --delete vs rsync --delete-after)

Hi, On Fri, Jan 26, 2024 at 04:11:39PM +0100, hw wrote: > I've never had issues with any UPS due to self tests. The batteries > need to be replaced when they are worn out. How often that is > required depends on the UPS and the conditions it is working in, > usually every 3--5 years. Out of int

Re: rsync --delete vs rsync --delete-after

On Thu, 2024-01-18 at 13:26 +0100, Ralph Aichinger wrote: > Hello fellow Debian users, > > On Thu, 2024-01-18 at 12:18 +0100, hw wrote: > > > Always use an UPS. > > > Here I have a somewhat contrarian view, I hope not to offend too much: It's not offending, you merely have a different opinion.

Re: rsync --delete vs rsync --delete-after

On 2024-01-18, Andy Smith wrote: > Could check the man page then like I said. > > Some options require rsync to know the full file list, so these > options disable the incremental recursion mode. These include: > --delete-before, --delete-after, --prune-empty-dirs, and > --delay-up

Re: rsync --delete vs rsync --delete-after

On Thu, 2024-01-18 at 21:44 +, Andy Smith wrote: > Hello, > > On Thu, Jan 18, 2024 at 10:01:46PM +0100, Michel Verdier wrote: > > On 2024-01-18, Andy Smith wrote: > > > If you use --delete-after (and some other options) then rsync has > > > to > > > check every file before it can do any work,

Re: rsync --delete vs rsync --delete-after

Hello, On Thu, Jan 18, 2024 at 10:01:46PM +0100, Michel Verdier wrote: > On 2024-01-18, Andy Smith wrote: > > If you use --delete-after (and some other options) then rsync has to > > check every file before it can do any work, whereas normally it will > > find a few files to work on and start work

Re: rsync --delete vs rsync --delete-after

On 2024-01-18, Andy Smith wrote: > If you use --delete-after (and some other options) then rsync has to > check every file before it can do any work, whereas normally it will > find a few files to work on and start work, meanwhile incrementally > scanning for more. Not sure of that. rsync always

Re: rsync --delete vs rsync --delete-after

>> > However, I have read that using rsync --delete instead of rsync -- >> > delete-after is faster and uses less memory, and so is more efficient.  >> I'd be surprised if it makes a significant difference. > If you use --delete-after (and some other options) then rsync has to > check every file be

Re: rsync --delete vs rsync --delete-after

Hello, On Wed, Jan 17, 2024 at 11:09:35PM -0500, Stefan Monnier wrote: > > However, I have read that using rsync --delete instead of rsync -- > > delete-after is faster and uses less memory, and so is more efficient.  > > I'd be surprised if it makes a significant difference. If you use --delete

Re: rsync --delete vs rsync --delete-after

On Thu, 2024-01-18 at 13:09 +, Michael Kjörling wrote: > > Definitely agree that a solid backup regimen (including regular > automated backups; at least one off-site copy _at least_ of critical, > hot data; and planning for the contingency that you need to restore > that backup onto a brand ne

Re: rsync --delete vs rsync --delete-after

On 18 Jan 2024 13:26 +0100, from r...@h5.or.at (Ralph Aichinger): > As a home/SOHO user, I'd rather have a working backup every few hours > or every day than some RAID10 wonder Definitely agree that a solid backup regimen (including regular automated backups; at least one off-site copy _at least_

Re: rsync --delete vs rsync --delete-after

On 2024-01-17, Default User wrote: > BTW(2), I do use rsnapshot with cron jobs to back up the internal SSD > to the primary backup drive daily (and weekly, monthly, yearly). But I > am not sure if I could also use it to do copies of the primary backup > drive to the secondary backup drive (maybe

Re: rsync --delete vs rsync --delete-after

Hello fellow Debian users, On Thu, 2024-01-18 at 12:18 +0100, hw wrote: > Always use an UPS. Here I have a somewhat contrarian view, I hope not to offend too much: For countries with stable electricity supplies (like Austria where I live) having a small UPS might actually lead to more problems

Re: rsync --delete vs rsync --delete-after

On 18 Jan 2024 12:15 +0100, from to...@tuxteam.de: >> **That "primary backup drive" is not a backup at all.** > > It is: against the situation you fat-finger something and react > before the next backup happens (this is a threat worth being taken > into account). For that case, a backup with more

Re: rsync --delete vs rsync --delete-after

On Wed, 2024-01-17 at 14:52 -0500, Default User wrote: > On Wed, 2024-01-17 at 10:29 -0800, Kushal Kumaran wrote: > > On Wed, Jan 17 2024 at 11:19:39 AM, Default User > > wrote: > > > Hello! > > > > > > Opinions, please. > > > > > > I use rsync to copy my primary backup drive to a secondary back

Re: rsync --delete vs rsync --delete-after

On Thu, Jan 18, 2024 at 11:05:01AM +, Michael Kjörling wrote: > On 17 Jan 2024 20:23 -0500, from hunguponcont...@gmail.com (Default User): [...] > Hold on. Let's pause right here. > > **That "primary backup drive" is not a backup at all.** It is: against the situation you fat-finger somethi

Re: rsync --delete vs rsync --delete-after

On 17 Jan 2024 20:23 -0500, from hunguponcont...@gmail.com (Default User): > BTW, the two backup drives are external 4 Gb USB HDDs. The secondary > backup drive is always kept away from the computer, in a locked steel > box, except when it is attached to the computer to have the primary > backup d

Re: rsync --delete vs rsync --delete-after

On 1/17/24 17:23, Default User wrote: On Wed, 2024-01-17 at 09:19 -0800, David Christensen wrote: On 1/17/24 08:19, Default User wrote: Opinions, please. ... Hi guys, thanks for the replies. YW. :-) BTW, the two backup drives are external 4 Gb USB HDDs. The secondary backup drive is al

Re: rsync --delete vs rsync --delete-after

> However, I have read that using rsync --delete instead of rsync -- > delete-after is faster and uses less memory, and so is more efficient.  I'd be surprised if it makes a significant difference. Stefan

Re: rsync --delete vs rsync --delete-after

On 2024-01-17, Default User wrote: > By "glitch", I mean anything that could interfere with the rsync copy > process. Possible causes: Whatever the cause you just have to get return code and restart rsync until it complete succesfully. Then you are sure to have an exact copy. To cope with error

Re: rsync --delete vs rsync --delete-after

On Wed, 2024-01-17 at 09:19 -0800, David Christensen wrote: > On 1/17/24 08:19, Default User wrote: > > Hello! > > > > Opinions, please. > > > > I use rsync to copy my primary backup drive to a secondary backup > > drive > > , so that the secondary backup drive is theoretically always an > > exac

Re: rsync --delete vs rsync --delete-after

On 18/1/24 04:19, David Christensen wrote: > I use rsync to copy my primary backup drive to a secondary backup drive Good morning I wonder why both processes don't copy from the original data; so that you don't copy a potential glitch in the first backup? on a separate matter Glitch? Pow

Re: rsync --delete vs rsync --delete-after

Hi, On Wed, Jan 17, 2024 at 02:52:49PM -0500, Default User wrote: > By "glitch", I mean anything that could interfere with the rsync copy > process. Possible causes: > - electrical outages, voltage spikes, voltage drops, "brownouts" > - mechanical failure > - earthquake > - lightning > - cat wal

Re: rsync --delete vs rsync --delete-after

On 17 Jan 2024 14:52 -0500, from hunguponcont...@gmail.com (Default User): > I am writing as someone who has lost data more than once over time, for > various reasons. The loss has ranged from slightly annoying, to soul- > rending catastrophe. It is NEVER appreciated. I think this gets closer to

Re: rsync --delete vs rsync --delete-after

On Wed, 2024-01-17 at 10:29 -0800, Kushal Kumaran wrote: > On Wed, Jan 17 2024 at 11:19:39 AM, Default User > wrote: > > Hello! > > > > Opinions, please. > > > > I use rsync to copy my primary backup drive to a secondary backup > > drive > > , so that the secondary backup drive is theoretically

Re: rsync --delete vs rsync --delete-after

On Wed, Jan 17 2024 at 11:19:39 AM, Default User wrote: > Hello! > > Opinions, please. > > I use rsync to copy my primary backup drive to a secondary backup drive > , so that the secondary backup drive is theoretically always an exact > copy of the primary backup drive. > > Here is the rsync co

Re: rsync --delete vs rsync --delete-after

On 1/17/24 08:19, Default User wrote: Hello! Opinions, please. I use rsync to copy my primary backup drive to a secondary backup drive , so that the secondary backup drive is theoretically always an exact copy of the primary backup drive. Here is the rsync command I use: time sudo rsync -aAXH

Re: rsync trying to load rdiff-backup

On 2022-05-08 18:27, AC wrote: On 2022-05-08 18:03, David wrote: On Mon, 9 May 2022 at 10:53, AC wrote: On 2022-05-08 16:45, David wrote: On Mon, 9 May 2022 at 07:24, AC wrote: Now here's a new discovery on the machines having problems: as a normal user I can rsync just fine to a remote m

Re: rsync trying to load rdiff-backup

On 2022-05-08 18:03, David wrote: On Mon, 9 May 2022 at 10:53, AC wrote: On 2022-05-08 16:45, David wrote: On Mon, 9 May 2022 at 07:24, AC wrote: Now here's a new discovery on the machines having problems: as a normal user I can rsync just fine to a remote machine. But if I'm using rsync

Re: rsync trying to load rdiff-backup

On Mon, 9 May 2022 at 10:53, AC wrote: > On 2022-05-08 16:45, David wrote: > > On Mon, 9 May 2022 at 07:24, AC wrote: > Now here's a new discovery on the machines having problems: as a normal > user I can rsync just fine to a remote machine. But if I'm using rsync > as root to send a backup to

Re: rsync trying to load rdiff-backup

On 2022-05-08 16:45, David wrote: On Mon, 9 May 2022 at 07:24, AC wrote: Due to some version mismatch issues I'm trying to switch over to rsync from rdiff-backup for backing up some files on my systems. On most of them this has worked with no issue but I have one system that appears to be try

Re: rsync trying to load rdiff-backup

On Mon, 9 May 2022 at 07:24, AC wrote: > > Due to some version mismatch issues I'm trying to switch over to rsync > from rdiff-backup for backing up some files on my systems. > > On most of them this has worked with no issue but I have one system that > appears to be trying to load rdiff-backup wh

Re: rsync copyed systemd-nspawn container won't start

Hi, [...] > Jan 11 15:22:55 dhanna systemd-nspawn[21268]: Failed to create > /init.scope control group: Operation not permitted [...] > Then I try it with > > debootstrap --variant=minbase --include > systemd,vim,libterm-readline-gnu-perl,iproute2,dialog,dbus stretch > /var/lib/machines/foo > >

Re: rsync failing to back up to synology server

On 2021-11-13 10:42, Dan Ritter wrote: Sharon Kimble wrote: After enduring a home move, I'm now trying to restart my rsync backups to my synology server, but none are working! I have this command for backing up my emacs - - --8<---cut here---start->8--- /us

Re: rsync failing to back up to synology server

Sharon Kimble wrote: > > After enduring a home move, I'm now trying to restart my rsync backups > to my synology server, but none are working! > > I have this command for backing up my emacs - > > - --8<---cut here---start->8--- > /usr/bin/rsync -avhz --updat

Re: rsync to NAS for backup

On Mon, Feb 15, 2021 at 12:39:29PM +, mick crane wrote: > Appears that to retain permissions need root at both ends of rsync. Not necessarily. If the server filesystem supports xattrs, you can use the --fake-super option with the rsync server, running as a non-root user that can write to the s

Re: rsync to NAS for backup

On Thu, Feb 18, 2021 at 05:06:33PM -0700, Charles Curley wrote: > On Thu, 18 Feb 2021 18:24:43 +0100 > wrote: > > > Care to name some of those limitations? > > > > (of course, rsync /is not/ a backup program in itself, but lets you > > build one with 10-30 lines around it). > > Why build one (w

Re: rsync to NAS for backup

On Thu, 18 Feb 2021 18:24:43 +0100 wrote: > Care to name some of those limitations? > > (of course, rsync /is not/ a backup program in itself, but lets you > build one with 10-30 lines around it). Why build one (which I have done) when you can get a perfectly good one from the Debian repos? E.g

Re: rsync to NAS for backup

On 2021-02-18 12:22, to...@tuxteam.de wrote: On Thu, Feb 18, 2021 at 06:59:03PM +0200, Teemu Likonen wrote: * 2021-02-18 11:13:25-0500, Gary Dale wrote: rsync is a quick & dirty backup tactic but it's got limitations. 1) files may stay around forever in the backup even if you've deleted them

Re: rsync to NAS for backup

On 2021-02-18 10:57, mick crane wrote: On 2021-02-15 12:39, mick crane wrote: On 2021-02-13 19:20, David Christensen wrote: On 2021-02-13 01:27, mick crane wrote: I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get to grips with it. If rsync from PC to NA

Re: rsync to NAS for backup

On Thu, Feb 18, 2021 at 07:21:01PM +0200, Andrei POPESCU wrote: [...] > In my opinion the point still stands, rsync (by itself) has significant > limitations as a backup program, which is probably also the reason why > several backup programs using rsync exist. Care to name some of those limit

Re: rsync to NAS for backup

On Thu, Feb 18, 2021 at 06:59:03PM +0200, Teemu Likonen wrote: > * 2021-02-18 11:13:25-0500, Gary Dale wrote: > > > rsync is a quick & dirty backup tactic but it's got limitations. > > > > 1) files may stay around forever in the backup even if you've deleted > > them from your main computer becau

Re: rsync to NAS for backup

On Jo, 18 feb 21, 18:59:03, Teemu Likonen wrote: > * 2021-02-18 11:13:25-0500, Gary Dale wrote: > > > rsync is a quick & dirty backup tactic but it's got limitations. > > > > 1) files may stay around forever in the backup even if you've deleted > > them from your main computer because you don't n

Re: rsync to NAS for backup

* 2021-02-18 11:13:25-0500, Gary Dale wrote: > rsync is a quick & dirty backup tactic but it's got limitations. > > 1) files may stay around forever in the backup even if you've deleted > them from your main computer because you don't need them. > > 2) you only have one copy of a file and that on

Re: rsync to NAS for backup

On 2021-02-18 16:13, Gary Dale wrote: On 2021-02-18 10:57, mick crane wrote: On 2021-02-15 12:39, mick crane wrote: On 2021-02-13 19:20, David Christensen wrote: On 2021-02-13 01:27, mick crane wrote: I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get

Re: rsync to NAS for backup

On 2021-02-15 12:39, mick crane wrote: On 2021-02-13 19:20, David Christensen wrote: On 2021-02-13 01:27, mick crane wrote: I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get to grips with it. If rsync from PC to NAS NAS changes the owner/group of files t

Re: rsync to NAS for backup

On 2021-02-13 19:20, David Christensen wrote: On 2021-02-13 01:27, mick crane wrote: I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get to grips with it. If rsync from PC to NAS NAS changes the owner/group of files to me/users which is probably no good fo

Re: rsync to NAS for backup

On 2021-02-13 01:27, mick crane wrote: I made a mistake and instead of getting a PC for backup I got a NAS. I'm struggling to get to grips with it. If rsync from PC to NAS NAS changes the owner/group of files to me/users which is probably no good for backing up. There's that problem then anothe

Re: rsync to NAS for backup

On Sat, 13 Feb 2021 09:27:54 + mick crane wrote: > I made a mistake and instead of getting a PC for backup I got a NAS. > I'm struggling to get to grips with it. > If rsync from PC to NAS NAS changes the owner/group of files to > me/users which is probably no good for backing up. Can you set

Re: rsync to NAS for backup

Is there an alternative if you want an incremental backup? Obviously you could use tar-ed archives with unprivileged permissions. If you did, you would get a huge network overhead. thks Toni Mas GPG 3F42A21D84D7E950 Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ En dissa

Re: rsync to NAS for backup

Hello, Disclaimer: I do not use and am not familiar with Sinology hardware and software and generally speaking, I am not knowledgeable in networking I would say that: - the owner:group names of a file on the PC you backup and the owner:group names of the backup files on the synology files

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Mon, 23 Nov 2020 11:17:56 -0500 Celejar wrote: Hello Celejar, >I made this same point in another email, but I just want to remind Indeed you did. And rightly so; It's possible that my messages could be construed as saying CM is the _only_ MUA capable of such configuration. That was not my

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020, at 16:55, Gareth Evans wrote: > > Once one sets up an MUA correctly, one only has to click 'Compose' for > > all the required fields, apart from Subject, to be filled in. > > When does clicking "compose" have this effect? In a good (probably standalone) MUA. In Fastmail's w

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 19:14:05 + Brad Rogers wrote: > On Sun, 22 Nov 2020 11:39:20 -0700 > Charles Curley wrote: > > Hello Charles, > > >Thank you. I just learned something useful about Claws-Mail. > > You're welcome. > > For those interested, Claws Mail has it's own mailing list. > > Sub

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 17:39:06 + "Gareth Evans" wrote: > > On Sun, 22 Nov 2020, at 17:08, Brad Rogers wrote: ... > > > With a suitable MUA (example; Claws Mail) when you create a folder for > > > mails from a mailing list, it's possible to set up default addresses for > > > To, From and Reply

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 11:39:20 -0700 Charles Curley wrote: Hello Charles, >Thank you. I just learned something useful about Claws-Mail. You're welcome. For those interested, Claws Mail has it's own mailing list. Subscribe here; or by

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 17:08:42 + Brad Rogers wrote: > With a suitable MUA (example; Claws Mail) when you create a folder for > mails from a mailing list, it's possible to set up default addresses > for To, From and Reply-To to be used for that folder. With Claws, > it's even possible to set up

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 17:39:06 + "Gareth Evans" wrote: Hello Gareth, >Thanks Brad, I may be a Claws convert! You're welcome, Gareth. -- Regards _ / ) "The blindingly obvious is / _)radnever immediately apparent" It's a very small world in the middle of a

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

I may be a Claws convert :) Thanks G On Sun, 22 Nov 2020, at 17:08, Brad Rogers wrote: > On Sun, 22 Nov 2020 16:55:19 + > "Gareth Evans" wrote: > > Hello Gareth, > > >On Sun, 22 Nov 2020, at 15:38, Brad Rogers wrote: > >> Once one sets up an MUA correctly, one only has to click 'Compose' f

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

> On Sun, 22 Nov 2020, at 17:08, Brad Rogers wrote: > > On Sun, 22 Nov 2020 16:55:19 + > > "Gareth Evans" wrote: > > > > Hello Gareth, > > > > >On Sun, 22 Nov 2020, at 15:38, Brad Rogers wrote: > > >> Once one sets up an MUA correctly, one only has to click 'Compose' for > > >> all the req

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020, at 17:20, to...@tuxteam.de wrote: > On Sun, Nov 22, 2020 at 04:55:19PM +, Gareth Evans wrote: > > [...] > > > Thanks to all who have replied pointing out the issues. > > No worries. Things happen. No need to defend yourself, I hope. > > > In my defence, I don't use c

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, Nov 22, 2020 at 04:55:19PM +, Gareth Evans wrote: [...] > Thanks to all who have replied pointing out the issues. No worries. Things happen. No need to defend yourself, I hope. > In my defence, I don't use conversation view in general (so lack experience) > and had imagined Fastmai

Re: Hijacking Threads [was: Re: rsync link corruption with -H and --link-dest]

On Sun, 22 Nov 2020 16:55:19 + "Gareth Evans" wrote: Hello Gareth, >On Sun, 22 Nov 2020, at 15:38, Brad Rogers wrote: >> Once one sets up an MUA correctly, one only has to click 'Compose' for >> all the required fields, apart from Subject, to be filled in. >When does clicking "compose" hav

  1   2   3   4   5   6   >