1

I have a simple script that backups Raspbian to a network share:

sudo dd if=/dev/mmcblk0 of="/mnt/NAS/backup.img"

When I manually run the script with sudo ./backup.sh, everything is fine, the write speed is about 25 MiB/s and the backup is finished in under 10 minutes (8 GB SD card).

To automate the process I added the script to the root crontab file but noticed that the backup becomes super slow and would take almost 8 hours.

I switched to root with sudo -i to check the dd output, and the write speed indeed drops to 300 KiB/s.

What could be the reason for this?

3
  • TBH I’ve no idea but a thought is the environment (path, variables, shell etc) are different but why that should have this impact I do not know. Maybe put a the code you use would help someone spot something? Are you sure target is equal before testing both runs (e.g. cleared down, trash empty etc) - I’ve seen a delay when the target had files and a byte level comparison was done not a checksum comparison...
    – user115418
    Jul 7 '20 at 21:30
  • Yes, everything is completely identical. The only code I'm running is the dd command I posted above. The system is idling, I can't see any reason why it would be so incredibly slow.
    – Dan
    Jul 8 '20 at 6:49
  • Bit baffled in that you are running a sudo command as root ?!? Wonder if it’s a lock condition - normally files will be open and/or locked and you are trying to back everything up on the SD card so /dev and temp files could also cause locks. It’s always better to back up when the system is inactive (i.e. pop the SD card into another machine) or skip some directories. Application level backups (e.g. config files / database etc) using rsync is better but you need to look at a rebuild strategy to use this effectively. Try setting BS higher - cuts down your time but hits the LAN traffic more.
    – user115418
    Jul 8 '20 at 11:23
1

Just wanted to point out a few problems with your script.

First, if you're doing this directly on your root FS, be aware that your backup may have filesystem errors because the FS keeps changing as you make the backup of it. Verify that your backup works!

Second, dd uses a tiny default block size of 512 bytes, so I'm actually surprised you got the performance reported in the first case. If you need the whole image anyway, why not just use cp, a tool optimized for copying?

Whatever is affecting the performance in your case is definitely not related to root. You simply cannot access a raw block device without root permissions, so dd must be running as root in both cases.

Perhaps cron is configured to run jobs with low priority? Or maybe there is a quote set for cron jobs?

3
  • Yes, I'm aware of the risks when using dd, that's why I always stop Home Assistant and other services that write log files first. Otherwise the logs in the backup get corrupted. I was looking for a simple way to backup the whole SD card so I can restore it in a couple of minutes if anything happens. The dd command always worked well when directly started with sudo. Guess I will check if I can achieve the same results with cp or another tool that creates .img files.
    – Dan
    Jul 9 '20 at 12:59
  • 1
    Update: I added "bs=1M" to the script, and now the cronjob is as fast as the direct script call. It's as the default block size of dd is different for the root user, which made the script slower. Anyway, it's working fine now.
    – Dan
    Jul 13 '20 at 7:20
  • @Dan That's not something I'd have expected, AFAIK dd determines the block size solely on the bs parameter, so I wonder how could it change all by itself. I don't think it's related to the root user: as I said, you are running dd as root in both cases. Anyway, I'm glad it worked out, and I wouldn't bother switching to cp if your script already works with dd. Jul 13 '20 at 7:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.