Back-up runs for 12+ hours and then fails

[Elmeromoto]

Tried running this the other day and then got the following error:

cp: cannot create regular file '/volume3/Transfer/syno_app_mover/Docker/extras/@docker/@docker/btrfs/subvolumes/ea292b0d243a3223ceea84d357c016c4e2e16d0f842ab51136f4d0c4f9c2f29c/usr/local/lib/node_modules/npm/docs/public/cli-commands/npm-access/index.html': No space left on device

I was re-backing up to an existing directory that hadn't fully backed up once before (re-ran the script after it failed once), so I figured it was related to either that or the buffer setting. I re-ran the script yesterday to an empty directory with a larger buffer and it's still running today (12+ hours). I'll see if this one fails and report back...but this doesn't feel like expected behavior. It shouldn't take this long to move under 500GB of files I'd think.

For context, the entire drive is ~600GB used and most of that is not in the Applications.

Other context: DS918+ Moving from SHR SSD to BTRFS HDD for backup. The SHR has ~1TB of available space and the BTRFS location has >5TB available space Total that I'm moving: <600GB Other errors during run: \e[0;33mWARNING\e[0m Failed to get size of /volume3/@apphome (had this for each folder)

[Elmeromoto]

Somewhat related, It would be nice to get a verbose mode so I could see everything that was happening on a line-by-line basis as it runs.

[007revad]

I'm going to change the backup and restore modes to use rsync instead copy.

A verbose mode would end up with only the last part being readable, unless you had a huge buffer or scrollback set in terminal or putty. I could add a log option to create a verbose log of every command.

[007revad]

v4.0.73

• Changed to use rsync instead of cp for backups to make backing up the same package again faster.

But I forgot about restore mode.