Automatically backing up cache drive apps dir and docker.img to protected array

Some time ago I posted how to do this for v5 (just appdata, no docker.img obviously).  I recently moved to v6 and figured I'd post this up to help others who want to do the same thing.  As with v5, all of this information can be found scattered through other posts in the forums, but I figured I'd create a single post with a how to.

 

My server has a cache drive which hosts the apps directory for my dockers as well as the docker.img.  As the cache is not fault tolerant, I wanted to backup the apps directory to the protected array periodically in case the cache drive were ever to fail.

 

Obviously the script would need to be modified to your particular needs, but it's a good starting point for those Linux novices like myself.  The script was named cache_backup.sh and placed in /boot/custom.  I backup to a fixed disk (disk3) but you can just as easily backup to a user share at /mnt/user/sharename.  Also, my application data directory is named apps (not appdata) and my docker.img does not sit at the root of the cache drive, it is at /cache/docker/docker.img.  You will need to modify the script according to how your directory structure is.

 

#!/bin/bash

#Stop Docker Apps
docker stop $(docker ps -a -q)

#Backup apps dir and Docker img via rsync
date >/var/log/docker_img_backup.log
date >/var/log/cache_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/docker/ /mnt/disk3/Backup/unRAID_cache/docker >>/var/log/docker_img_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/apps/ /mnt/disk3/Backup/unRAID_cache/apps >>/var/log/cache_backup.log

#Start Docker Apps
/etc/rc.d/rc.docker start

 

You then need to add the script to cron.weekly on every reboot.  This is done by adding the following to the go script.

 

#Add cache backup script to cron
cp /boot/custom/cache_backup.sh /etc/cron.weekly

 

EDIT: Make sure to use a Linux compatible editor, like Notepad++ for Windows, to avoid DOS line endings.

 

EDIT2: If one of the apps you are backing up is Plex, you need to make sure you rsync to a disk share (disk3 in my example above) and not to a user share.  Backing up Plex to a user share will generate lots of "unable to set time" errors.

so if I have everything in the default locations and a user share named "BACKUPS" with folder in there named "unRAID_cache", would the script look like this?

 

#!/bin/bash

#Stop Docker Apps
docker stop $(docker ps -a -q)

#Backup apps dir and Docker img via rsync
date >/var/log/docker_img_backup.log
date >/var/log/cache_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/docker.img /mnt/user/BACKUPS/unRAID_cache/docker.img >>/var/log/docker_img_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/appdata/ /mnt/user/BACKUPS/unRAID_cache/appdata >>/var/log/cache_backup.log

#Start Docker Apps
/etc/rc.d/rc.docker start

You got it.  That's exactly what it would need to look like.

Cool 

 

Ran it manually and caught the DOS line ending fubar ("bad interpreter"). Fixed it and its doing its first backup now. Thanks for posting this.

Yes, I was going to say make sure you use a Linux compatible editor like Notepad++, but I forgot.  Thanks for the reminder and I'll add that to the OP.  Glad you got it working!

I did use Notepad++ lol. Brand new install on new laptop and its default is MSDOS format. Easy to fix file using Edit | EOL Conversion.

Thanks for this!  I actually took it one step further...I keep 7 days of backups. I also grab a copy of the flash drive. A full backup takes 30-45 minutes, so its no big deal if its down for that long in the middle of the night.

 

#!/bin/bash

#Set date variables for today and 7 days ago
time_stamp=$(date +%Y-%m-%d)
seven_days_ago=$(date +%Y-%m-%d --date="7 days ago")

#Create backup folder for today
backup_path="/mnt/disk1/CacheBackup/${time_stamp}"
mkdir -p "${backup_path}"

#Stop Plugins
/etc/rc.d/rc.plexmediaserver stop

#Stop Docker Apps
docker stop $(docker ps -a -q)

#Backup apps dir and Docker img via rsync
date >/var/log/docker_img_backup.log
date >/var/log/cache_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/docker/ $backup_path/docker >>/var/log/docker_img_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/appdata/ $backup_path/appdata >>/var/log/cache_backup.log

#Backup flash
/usr/bin/rsync -avrtH --delete /boot/ $backup_path/boot >>/var/log/flash_backup.log

#Start Docker Apps
/etc/rc.d/rc.docker start

#Start Plugins
/etc/rc.d/rc.plexmediaserver start

#Delete oldest backup folder
rm -r /mnt/disk1/CacheBackup/${seven_days_ago}

Thanks for this!  I actually took it one step further...I keep 7 days of backups. I also grab a copy of the flash drive. A full backup takes 30-45 minutes, so its no big deal if its down for that long in the middle of the night.

 

#!/bin/bash

#Set date variables for today and 7 days ago
time_stamp=$(date +%Y-%m-%d)
seven_days_ago=$(date +%Y-%m-%d --date="7 days ago")

#Create backup folder for today
backup_path="/mnt/disk1/CacheBackup/${time_stamp}"
mkdir -p "${backup_path}"

#Stop Plugins
/etc/rc.d/rc.plexmediaserver stop

#Stop Docker Apps
docker stop $(docker ps -a -q)

#Backup apps dir and Docker img via rsync
date >/var/log/docker_img_backup.log
date >/var/log/cache_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/docker/ $backup_path/docker >>/var/log/docker_img_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/appdata/ $backup_path/appdata >>/var/log/cache_backup.log

#Backup flash
/usr/bin/rsync -avrtH --delete /boot/ $backup_path/boot >>/var/log/flash_backup.log

#Start Docker Apps
/etc/rc.d/rc.docker start

#Start Plugins
/etc/rc.d/rc.plexmediaserver start

#Delete oldest backup folder
rm -r /mnt/disk1/CacheBackup/${seven_days_ago}

 

Suggestion: Instead of storing 7 discreet different copies why not use --link-dest=/PATH to Previous Backup/ to create hard links for unchanged files?

 

Idea from here

Thanks for this!  I actually took it one step further...I keep 7 days of backups. I also grab a copy of the flash drive. A full backup takes 30-45 minutes, so its no big deal if its down for that long in the middle of the night.

 

#!/bin/bash

#Set date variables for today and 7 days ago
time_stamp=$(date +%Y-%m-%d)
seven_days_ago=$(date +%Y-%m-%d --date="7 days ago")

#Create backup folder for today
backup_path="/mnt/disk1/CacheBackup/${time_stamp}"
mkdir -p "${backup_path}"

#Stop Plugins
/etc/rc.d/rc.plexmediaserver stop

#Stop Docker Apps
docker stop $(docker ps -a -q)

#Backup apps dir and Docker img via rsync
date >/var/log/docker_img_backup.log
date >/var/log/cache_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/docker/ $backup_path/docker >>/var/log/docker_img_backup.log
/usr/bin/rsync -avrtH --delete /mnt/cache/appdata/ $backup_path/appdata >>/var/log/cache_backup.log

#Backup flash
/usr/bin/rsync -avrtH --delete /boot/ $backup_path/boot >>/var/log/flash_backup.log

#Start Docker Apps
/etc/rc.d/rc.docker start

#Start Plugins
/etc/rc.d/rc.plexmediaserver start

#Delete oldest backup folder
rm -r /mnt/disk1/CacheBackup/${seven_days_ago}

 

Suggestion: Instead of storing 7 discreet different copies why not use --link-dest=/PATH to Previous Backup/ to create hard links for unchanged files?

 

Idea from here

 

Thanks! I will look into that.

You should also be aware that the running/stopped state of the array is stored on the flash in super.dat along with the array configuration. If you boot from a backup that was taken with the array running, unRAID will assume an unclean shutdown and start a correcting parity check.

You should also be aware that the running/stopped state of the array is stored on the flash in super.dat along with the array configuration. If you boot from a backup that was taken with the array running, unRAID will assume an unclean shutdown and start a correcting parity check.

 

Its mainly just to keep my share settings, logs etc.  I would never restore the entire thing in the event of a DR situation.

You should also be aware that the running/stopped state of the array is stored on the flash in super.dat along with the array configuration. If you boot from a backup that was taken with the array running, unRAID will assume an unclean shutdown and start a correcting parity check.

 

Its mainly just to keep my share settings, logs etc.  I would never restore the entire thing in the event of a DR situation.

What is your plan to retrieve the backup for the flash drive if the array isn't bootable? It's a little bit of a chicken and egg situation, so I'm curious what your course of action would be if the flash drive dies.

 

I would set up a fresh flash, assign a few drives at a time as data only until I found my backup, then copy what I wanted back out to the new flash and work from there.

 

Do you have a more elegant solution in mind?

What is your plan to retrieve the backup for the flash drive if the array isn't bootable? It's a little bit of a chicken and egg situation, so I'm curious what your course of action would be if the flash drive dies.

 

I would set up a fresh flash, assign a few drives at a time as data only until I found my backup, then copy what I wanted back out to the new flash and work from there.

 

Do you have a more elegant solution in mind?

 

This is why I don't backup my flash to the array.  Since the data on the flash is fairly static (except for logs, or when you make changes to settings), I personally don't think it needs to be backed up regularly. 

 

What I do is keep a backup of the flash off-array, on my personal machine.  Whenever I update unRAID OS, or change settings, add shares, etc (which isn't very often) I make a new backup of the flash.

I want to say, thanks for this. I am working on it and thinking about how I might want to modify your appraoch for my own uses.

 

I do have a question. If you have a scheduled monthly parity check, what happens if the weekly backup happens to fall during when that parity check is running?

I want to say, thanks for this. I am working on it and thinking about how I might want to modify your appraoch for my own uses.

 

I do have a question. If you have a scheduled monthly parity check, what happens if the weekly backup happens to fall during when that parity check is running?

 

I'm pretty sure it would process as normal. May be a bit slower but it won't hurt anything.

I want to say, thanks for this. I am working on it and thinking about how I might want to modify your appraoch for my own uses.

 

I do have a question. If you have a scheduled monthly parity check, what happens if the weekly backup happens to fall during when that parity check is running?

 

I'm pretty sure it would process as normal. May be a bit slower but it won't hurt anything.

 

What interwebtech said. It processes normally and the parity check will take a little longer than usual.

I want to say, thanks for this. I am working on it and thinking about how I might want to modify your appraoch for my own uses.

 

I do have a question. If you have a scheduled monthly parity check, what happens if the weekly backup happens to fall during when that parity check is running?

 

I'm pretty sure it would process as normal. May be a bit slower but it won't hurt anything.

 

What interwebtech said. It processes normally and the parity check will take a little longer than usual.

 

Great that is good news!

 

 

I hate to double post but this ran last night and apparently I don't have my rsycn command exactly right.

 

Last night this ran, and this morning I woke up to a email from unraid with the following.

 

Email Title:

cron for user root /usr/bin/run-parts /etc/cron.weekly 1> /dev/null

 

rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/art/com.plexapp.agents.thetvdb_c0f70e5086657c512bbca9630ca3bc944410473a": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/banners/com.plexapp.agents.thetvdb_64adbc5d6351ee8dda83375e41704538184c42d4": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/banners/com.plexapp.agents.thetvdb_ceec821c920d309167ca239367f179e3ffc6c37e": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/posters/com.plexapp.agents.thetvdb_43252ad8c6f8edf2b97530cd0ec937123a151813": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/posters/com.plexapp.agents.thetvdb_45bd738ccb586fe24381611de3607888972f5967": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/1/posters/com.plexapp.agents.thetvdb_0ecac05d37b2a3a39838723d31db2b7cb3b3cfa8": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/1/posters/com.plexapp.agents.thetvdb_eeafb5b567bf4ab1d7ed7d2a542fd7d723bf813d": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/2/posters/com.plexapp.agents.thetvdb_13d557d21575bfdbfac1aaab0bc70266267153a0": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/2/posters/com.plexapp.agents.thetvdb_fef91e7c36586cf4a2a0d2ebc21c9cd18a4b1b3f": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/3/posters/com.plexapp.agents.thetvdb_6a2da25bf008ff522e87e667805f63b5dd58d61b": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/3/posters/com.plexapp.agents.thetvdb_c85138137a44e47f25883f79e36fe1a4a5b0f324": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/4/posters/com.plexapp.agents.thetvdb_7531c3b09d901cf6182181bede38ba4ca3387faf": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/4/posters/com.plexapp.agents.thetvdb_bac938dc51c8125f8a06f3e6b85a38e8dfea2214": No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.0]

 

I did add a new show to my network this past week, so I think these files / directories were brand new and don't already exist on the destination. I think the next time this runs this won't have the same problem.

 

Is there any ideas on how to resolve this though, for future times that the files change?

 

Here's what my rsync is set up as currently.

rsync -avp --delete /mnt/cache/Apps/ /mnt/user/"Unraid Backup"/ >>/var/log/cache_backup.log

 

I hate to double post but this ran last night and apparently I don't have my rsycn command exactly right.

 

Last night this ran, and this morning I woke up to a email from unraid with the following.

 

Email Title:

cron for user root /usr/bin/run-parts /etc/cron.weekly 1> /dev/null

 

rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/art/com.plexapp.agents.thetvdb_c0f70e5086657c512bbca9630ca3bc944410473a": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/banners/com.plexapp.agents.thetvdb_64adbc5d6351ee8dda83375e41704538184c42d4": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/banners/com.plexapp.agents.thetvdb_ceec821c920d309167ca239367f179e3ffc6c37e": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/posters/com.plexapp.agents.thetvdb_43252ad8c6f8edf2b97530cd0ec937123a151813": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/posters/com.plexapp.agents.thetvdb_45bd738ccb586fe24381611de3607888972f5967": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/1/posters/com.plexapp.agents.thetvdb_0ecac05d37b2a3a39838723d31db2b7cb3b3cfa8": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/1/posters/com.plexapp.agents.thetvdb_eeafb5b567bf4ab1d7ed7d2a542fd7d723bf813d": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/2/posters/com.plexapp.agents.thetvdb_13d557d21575bfdbfac1aaab0bc70266267153a0": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/2/posters/com.plexapp.agents.thetvdb_fef91e7c36586cf4a2a0d2ebc21c9cd18a4b1b3f": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/3/posters/com.plexapp.agents.thetvdb_6a2da25bf008ff522e87e667805f63b5dd58d61b": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/3/posters/com.plexapp.agents.thetvdb_c85138137a44e47f25883f79e36fe1a4a5b0f324": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/4/posters/com.plexapp.agents.thetvdb_7531c3b09d901cf6182181bede38ba4ca3387faf": No such file or directory (2)
rsync: failed to set times on "/mnt/user/Unraid Backup/Plex/library/Plex Media Server/Metadata/TV Shows/a/9b4439b55463ffed58b8720ba583c28c27057ce.bundle/Contents/_combined/seasons/4/posters/com.plexapp.agents.thetvdb_bac938dc51c8125f8a06f3e6b85a38e8dfea2214": No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1165) [sender=3.1.0]

 

I did add a new show to my network this past week, so I think these files / directories were brand new and don't already exist on the destination. I think the next time this runs this won't have the same problem.

 

Is there any ideas on how to resolve this though, for future times that the files change?

 

Here's what my rsync is set up as currently.

rsync -avp --delete /mnt/cache/Apps/ /mnt/user/"Unraid Backup"/

Me too.

Me three  :'(

The script ran last night for me as well.  I did not receive an email regarding errors.  I also manually checked the log file and there were no errors.

 

After a bit of searching around I found this:  https://lime-technology.com/forum/index.php?topic=36622.msg349384#msg349384

 

Gundamguy, you are rsyncing to a user share, so this might be your issue.  Trurl and interwebtech, are you rsyncing to a user share as well?

 

 

yes the target is a user share

 

/mnt/user/BACKUPS/unRAID_cache/

 

PS. the share is restricted to just Disk 1 so I will edit the path to use Disk 1.

 

Odd that running it manually there are no errors.

yes the target is a user share

 

/mnt/user/BACKUPS/unRAID_cache/

 

Assuming that user share doesn't span multiple disks, change the script to point to the disk share and see if the errors resolve.  If that user share spans multiple disks, you'll have to create a share for cache backups that only exists on a single disk and point the rsync to the disk share instead of the user share.

yes the target is a user share

 

/mnt/user/BACKUPS/unRAID_cache/

 

PS. the share is restricted to just Disk 1 so I will edit the path to use Disk 1.

 

Odd that running it manually there are no errors.

Mine was almost identical, except my Backups share is restricted to disk5. I have changed the script to use the disk instead.

 

I also had no issues when I first ran it manually.

yes the target is a user share

 

/mnt/user/BACKUPS/unRAID_cache/

 

PS. the share is restricted to just Disk 1 so I will edit the path to use Disk 1.

 

Odd that running it manually there are no errors.

Mine was almost identical, except my Backups share is restricted to disk5. I have changed the script to use the disk instead.

 

I also had no issues when I first ran it manually.

 

I think this error is only going to happen on the first run / when there are new files or directories to rsync. On the second run those directories exist so rsync doesn't have the same problem. I'm not sure why this would be different between user shares and just directly addressing the disk though.