Per Chr-Block-Rewrite-Per Chr-Block-Seeks. Version 2.00 -Sequential Output-Sequential Input-Random. Here’s the bonnie++ results: # bonnie++ -d /tmp -u paul bonnie++ ?ĭrives are WD Red 1TB NAS (5400 RPM SATA 6 Gb/s 64MB Cache / WD10EFRX). I don’t see an obvious reason why the IO should be that slow, but then again I don’t have an idea how fast the HDDs are. That is a lot IO-load for only 2 CPU cores. Which (a) says the max is 3 and (b) is why I got confused about the parameter value. The man page shows: -v, -verbose n be verbose (specify multiple times or a level using -verbose=n, max level/times is 3) Although, the highest verbosity level is actually only 2. It’s interpreted as -verbose and backup path 3. 0.0.0.1 Search document 1 Manage Modules: 1.1 Pre-conditions: 1.1.1 Creating a Superadmin user: 1.2 Installing Module: 1.3 Updating Module: 1.4 Deleting or Uninstalling Module: 1.4.1 Module not appearing in sidebar: 1.4. Sudo nohup 2>&1 strace -e trace=%file -tt -T -e 'signal=!sigurg' -p 484918 & I’m now logging strace output to a file and will come back and read it later: This was copied at 10:55, 22 minutes after the last line of output. Restart_syscall() = -1 ETIMEDOUT (Connection timed out) Here’s some strace output from one of the child processes: # strace -p 549951 Are there any warning show in the kernel log by dmesg? Is the RAID in a healthy state? Judging from the amount of data added by the backup, that is far too slow, even for a HDD. restic takes about a quarter of an second to read each file. It looks like there is some serious problem with the IO performance. You could use restic diff snapshot-a snapshot-b to get a list of files which have changed between the snapshots. That is we can probably rule out the case that the server is swapping itself to death.ġ50k changed files are indeed a lot.

That is somewhat curious as prune requires much more memory than backup. The pastebin log shows that restic is able to prune the repository in a few minutes. By restricting access to resources within a security group from the internet (0.0.0.0/0) remote access can be controlled to internal systems. Paulschreiber: Files: 68511 new, 149658 changed, 2547481 unmodifiedĪt that amount of changes, I’d expect the backup to take between 5-15 minutes. How do I determine the cause of this slowdown/unresponsiveness so I can fix it? (Aside: to my untrained eye, 149658 seems like a high change count for one week.) Restic backup -exclude-file=/usr/local/restic/exclude / > /var/log/restic.logįrom the log: Files: 68511 new, 149658 changed, 2547481 unmodifiedĭirs: 9892 new, 26049 changed, 204325 unmodifiedĪdded to the repository: 5.352 GiB (5.355 GiB stored) I have a cron job that runs incremental backups once a week like this: in a colo with a synchronous, fast connection via gigabit ethernet.24 GB RAM, two mirrored 1TB drives (SATA HDs not SSDs), btrfs filesystem.While it is running, my server is unresponsive to requests (primarily web requests to apache). Restic incremental backups take a long time (17 hours).

Ultimate backup v1.0.0.0