I have a simple backup script, which also creates a tar/gzip archive of local data to an external USB device and then copies that archive to a second USB device.
For example:
usb1="/mnt/usbone"
usb2="/mnt/usbtwo"
source="/home/user"
tar cfz ${usb1}/source.tar.gz ${source}
cp -ar ${usb1}/source.tar.gz ${usb2}
This seems like it could be optimized to have tar
create copies on both drives, instead of creating one archive, which is copied afterwards. The resulting archive is rather small (<1GB). I am aware that this is not a safe approach for a backup.
Edit: I've quickly tested the solution from Archemar and comapred the approaches. For good measure, I also tested the initial approach with rsync
. See results with time
(not bash time, /usr/bin/time) and the script I used to test this.
Source is created with dd if=/dev/urandom bs=1M count=1024 of=/tmp/random.blob
. Host is a Raspberry Pi 3B running from a microSD card, the mounted targets are USB 2.0 flash drives (${a}
and ${b}
).
a.sh (tar and cp):
tar cfz ${a}/r1.tar.gz ${s}
cp -ar ${a}/r1.tar.gz ${b}/r1.tar.gz
b.sh (tar and tee):
tar cfz - ${s} | tee ${a}/r2.tar.gz > ${b}/r2.tar.gz
c.sh (tar and rsync):
tar cfz ${a}/r3.tar.gz ${s}
rsync -aW ${a}/r3.tar.gz ${b}/r3.tar.gz
Results:
# /usr/bin/time -v bash a.sh
Command being timed: "bash a.sh"
User time (seconds): 218.71
System time (seconds): 28.33
Percent of CPU this job got: 68%
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:03.13
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2480
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 41
Minor (reclaiming a frame) page faults: 1250
Voluntary context switches: 45519
Involuntary context switches: 25576
Swaps: 0
File system inputs: 3668157
File system outputs: 4197336
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
# /usr/bin/time -v bash b.sh
Command being timed: "bash b.sh"
User time (seconds): 221.64
System time (seconds): 28.62
Percent of CPU this job got: 85%
Elapsed (wall clock) time (h:mm:ss or m:ss): 4:53.98
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2536
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 31
Minor (reclaiming a frame) page faults: 1162
Voluntary context switches: 68310
Involuntary context switches: 35582
Swaps: 0
File system inputs: 2101321
File system outputs: 4197832
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
# /usr/bin/time -v bash c.sh
Command being timed: "bash c.sh"
User time (seconds): 235.24
System time (seconds): 35.01
Percent of CPU this job got: 74%
Elapsed (wall clock) time (h:mm:ss or m:ss): 6:04.03
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 2652
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 40
Minor (reclaiming a frame) page faults: 2310
Voluntary context switches: 65402
Involuntary context switches: 45179
Swaps: 0
File system inputs: 4200957
File system outputs: 4197496
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
To my surprise, the results are not that distinct. File system inputs: 2101321
is quite a bit lower with the tar/tee approach though, which I hope is good for the SD card's life.