Hello Jonas, Welcome to rdiff-backup ! Let me try to help you a bit more with you problem.
First, the first backup always take alot of time because rdiff-backup is not like a simple copy and alot of overhead are done in the background to put in place the first version of the data. Second, with your use case of 400GB, I would not expect a very long elapsed time for subsequent backup. I have a couple of backups with similar size and it roughly takes ~10-20 minutes over the Internet with 400Mbps. But you might not have the same setup as I do. If $HOME and $DRIVE are both local, It's quite simple to narrow the problem. While running the backup with you command line, you might want to check how the IO of your computer behaves. In the command line, try executring `iostat -x -m 3` and take a look at the '%util' column. It displays the percentage utilisation of the disk. If the value is near 90%, you have found the culprit. The IO is your bottleneck. To help the situation, you might want to run the backup without fsync. When Fsync is enabled, it forces the system to wait until the data is written to the disk and persisted. For slow drives on USB, it may have a huge impact on the performance. So try running rdiff-backup with `--no-fsync`. On Tue, Jun 1, 2021 at 10:33 AM Yves Bellefeuille <y...@storm.ca> wrote: > Alvin Starr <al...@netvel.net> wrote: > > > I thought rdiff-backup like rsync keeps track of the file metadata > > like size and creation date to skip reading the data again if the > > file has not been updated? > > I assume rdiff-backup does the same thing to decide if a file has > changed, but if there's a change, rsync simply throws away the old > version. > > rdiff-backup notes the changes and keeps older versions (depending on > the options) so you're not limited to only one previous version. > That's the whole point. > > -- > Yves Bellefeuille > <y...@storm.ca> > > > > -- IKUS Software inc. https://www.ikus-soft.com/ 514-971-6442 130 rue Doris St-Colomban, QC J5K 1T9
