@timconsidine
I think your test just reflects the situation when everything is working as supposed.
as I mentioned, to really check the situation when it was not working, one has to throttle a VM's throughput down to 11MB/s, as it was, when the "stalling-behavior" of cloudron's backup was seen. for every other situation, we know it's working.
after I had contact with support and they tinkered with the host, it's also working on my VM as supposed.
but this does not mean, there is not a SW-glitch/race-condition, or something else in CLDRN in that edge-case, which makes backup unreliable.
I'm on the same page as @robi mentioned here
It's about resilience and recovery. It's a software issue.
@nebulon, at the moment I don't have a dedi-host available to replicate that issue, nor that I would have enough time – sry.
but I have little script running per cron every 15min to check the throughput, to have a statistic at hand, when it happens again. In the last 6 days, it shows values between 45 - 85 MB/s, with an average of 71MB/s on 520 values.
which is somehow ok.
cat /usr/local/bin/do_troughput_test
#!/bin/bash
# test disk-trougput with dd
SOURCE=/root/throughput-testfile.img
TARGET=/tmp/test.img
LOG=/root/throughput-statistics.txt
[ -f $SOURCE ] || {
printf "No source file $SOURCE found, creating one\n"
dd if=/dev/urandom of=$SOURCE bs=1024 count=5M status=none
printf " done\n"
}
# clear caches
echo "Clearing cache"
echo 3 > /proc/sys/vm/drop_caches
echo "removing target"
rm -f $TARGET
date | tee -a $LOG
/usr/bin/time -a -o $LOG dd if=$SOURCE of=$TARGET bs=1024 count=5M conv=fdatasync,notrunc 2>&1 |grep -v records | tee -a $LOG
