May 3, 201214 yr I am using my cache drive as the data storage location for Plex, CouchPotato, SickBeard and SABnzbd in a directory called .plugins. I would like to back up the contents of this directory to a location on my protected array, say once a week, so if the cache drive ever fails I won't have to recreate everything. What is the best way to go about doing this? I tried searching but didn't really find any suggestions or solutions. Thanks
May 3, 201214 yr If you don't want to live dangerously stop all the services/applications using the folders in question, then copy the contents, then start the services/applications again. Otherwise copy the contents and hope for the best. I don't use plex, but both CouchPotato and Sickbeard employ databases for storing data about the files you're interested in. If those databases get corrupt, recreating them will be a pain. The easiest way to ensure you've got them (properly) backed up is to stop their related services and back up the configuration settings as well as the database. That way you can restore them (after stopping the related services) in the event of a failure.
May 3, 201214 yr An rsync copy I would guess.. But just for my information; why not just host the files on an array disk ? That way the data will be as safe as everything else on your sever, protected by parity..
May 3, 201214 yr Author An rsync copy I would guess.. But just for my information; why not just host the files on an array disk ? That way the data will be as safe as everything else on your sever, protected by parity.. The main reasons is to keep the array disks spun down at much as possible to prolong their lifespan. Plex in particular keeps the disk is it stored on constantly spun up. By having the applications stored there and data downloaded to the cache disk allows my array disks to stay spun down the whole time I am not using it save for when the mover script moves the data once a day.
May 3, 201214 yr Make a script that stops, does an rsync, and then starts the services. Copy the script to /etc/weekly, in the go file.
May 3, 201214 yr I have a similar setup and also try to avoid spinning up the array drives. My Microserver is on 24/7 and most of the time just the cache drive is spun up, resulting in under 30W power consumption. I store new Movies and TV shows plus some personal files on my cache drive. Occasionally, I'll manually move stuff I want to keep from the cache drive to an array drive -- probably less than once a week. I use Midnight Commander for that. But, every day, a cron script runs that just lists the contents of my TV and Movie folders on the cache drive. It puts those lists on disk1. That way, if the cache drive dies, I can reconstruct the contents pretty easily from that list. I don't copy or move the actual files, as they are probably going to be deleted after a while. 0 4 * * * ls /mnt/cache/TV >/mnt/disk1/Backups/TV-cache.rtf 0 4 * * * ls /mnt/cache/Movies >/mnt/disk1/Backups/Movies-cache.rtf For the personal data, I copy that data from the cache drive to an array drive on a regular basis. I copy rather than move so I can work on the files on the cache drive and not have the array drives spin up. Finally, I've just started using Google Drive and MS SkyDrive for cloud storage. I put some large, unchanging files on my free 25GB SkyDrive. I have SyncBack (free) running every day -- small files on my cache drive that change frequently are zipped (and encrypted) on to my Google Drive folder on a PC. That is automatically synced to the cloud. These are the folders that I do that with: * Personal data * The entire contents of //server/flash * SickBeard folder * nzbget and .nzbgetweb (also contains nzbgetter setup) Currently that uses 0.87GB of my free 5GB Google Drive.
May 3, 201214 yr An rsync copy I would guess.. But just for my information; why not just host the files on an array disk ? That way the data will be as safe as everything else on your sever, protected by parity.. The main reasons is to keep the array disks spun down at much as possible to prolong their lifespan. Plex in particular keeps the disk is it stored on constantly spun up. By having the applications stored there and data downloaded to the cache disk allows my array disks to stay spun down the whole time I am not using it save for when the mover script moves the data once a day. Ok, gottit, but that way your cache drive is spun up all of the time.. In my setup I have routed all "continuous" disk access to the same drive (my music library, backup and documents), they fit on one drive that is indeed allmost allways spun up.. So power wise that gives you the same result. Also, If that array drive fails I will be protected by the parity, stuff stored on the cache drive is not (even if you backup it daily towards the array you still run the risk of that day of data loss. To each his own but I concluded that (for me) it is more efficient to use the array !
May 3, 201214 yr Author An rsync copy I would guess.. But just for my information; why not just host the files on an array disk ? That way the data will be as safe as everything else on your sever, protected by parity.. The main reasons is to keep the array disks spun down at much as possible to prolong their lifespan. Plex in particular keeps the disk is it stored on constantly spun up. By having the applications stored there and data downloaded to the cache disk allows my array disks to stay spun down the whole time I am not using it save for when the mover script moves the data once a day. Ok, gottit, but that way your cache drive is spun up all of the time.. In my setup I have routed all "continuous" disk access to the same drive (my music library, backup and documents), they fit on one drive that is indeed allmost allways spun up.. So power wise that gives you the same result. Also, If that array drive fails I will be protected by the parity, stuff stored on the cache drive is not (even if you backup it daily towards the array you still run the risk of that day of data loss. To each his own but I concluded that (for me) it is more efficient to use the array ! The stuff that's on there doesn't change frequently enough that if lost a couple days since the last backup that it'll be a pain for me to recreate from the last backup. Also, my array consists of all 2TB+ disks and my cache drive is a little 320GB 7200RPM laptop disk. I have about 15 of those laptop disks left over from a project at work so if it dies it costs me nothing to pop a new one in there whereas with a failed 2TB disk is going to cost me > $100 to replace if it isn't in warranty. So the cache disk I am almost looking at as disposable, just not the data on the disk.
April 7, 201313 yr I know I'm resurrecting this thread from the dead, but I'm also interested in figuring out how to do this. I'm still a Linux novice and although I have learned a lot since I built my unRAID server, this is a bit over my head. I'm wondering if anyone else has done this and could share the scripts, etc., or help me to struggle my way through it. I'm currently reading up on rsync and scripting. What I'm looking to do is what dgaschk recommended further up in the thread, "Make a script that stops, does an rsync, and then starts the services. Copy the script to /etc/weekly, in the go file." Thanks for the help!
April 8, 201313 yr I put a topic on backing up the cache drive here in the Migration wiki article. Kevin
April 8, 201313 yr I put a topic on backing up the cache drive here in the Migration wiki article. Kevin Thank you very much, hadn't seen that. Off to configure it!
April 8, 201313 yr So I successfully created a script to stop the services, backup the cache drive via rsync (thanks stchas), and restart the services. Figured I'd post it here for anyone else who doesn't know how to do it. I didn't, but figured it out pretty easily for a Linux novice. I want to learn more about Linux, so the experience was well worth it. I also added the script to cron.weekly according to stchas guide so that it runs weekly. Of course, if anyone were to use it, the script would need to be modified to stop and restart the appropriate services, as well as backup to the correct location. #!/bin/bash #Stop services /etc/rc.d/rc.plexmediaserver stop /etc/rc.d/rc.sabnzbd stop /etc/rc.d/rc.sickbeard stop /etc/rc.d/rc.couchpotato_v2 stop #Backup cache via rsync date >/var/log/cache_backup.log /usr/bin/rsync -avrtH --delete /mnt/cache/apps/ /mnt/disk3/Backup/unRAID_cache >>/var/log/cache_backup.log #Start services /etc/rc.d/rc.plexmediaserver start /etc/rc.d/rc.sabnzbd start /etc/rc.d/rc.sickbeard start /etc/rc.d/rc.couchpotato_v2 start
August 8, 201411 yr Sorry to revive an old thread but I am having trouble getting this task to run automatically. I have created a backup script file which is located in the /boot/custom/bin folder #!/bin/bash #Stop services /etc/rc.d/rc.plexmediaserver stop #Backup cache via rsync date >/var/log/cache_backup.log /usr/bin/rsync -avrtH /mnt/cache/apps/ /mnt/disk3/BACKUPS/unRAID_cache >>/var/log/cache_backup.log #Start services /etc/rc.d/rc.plexmediaserver start I've also added this line to my Go file: cp /boot/custom/bin/cache_backup.sh /etc/cron.daily I can run the script manually but it will not run automatically. Is there anything I am not doing? Any help would be greatly appreciated!
August 8, 201411 yr Here it is in full: #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & #Backup cache via rsync cp /boot/custom/bin/cache_backup.sh /etc/cron.daily
August 8, 201411 yr Result is: root@Tower:~# ls -La /etc/cron.dailyls -La /etc/cron.daily /bin/ls: cannot access /etc/cron.dailyls: No such file or directory /etc/cron.daily: ./ ../ logrotate* plexupdater*
August 8, 201411 yr It looks as though you pasted the command twice I did Proper result: root@Tower:~# ls -La /etc/cron.daily ./ ../ logrotate* plexupdater*
August 9, 201411 yr Are you certain the go file is the one on the server and not a local copy? What does the following return? cp /boot/custom/bin/cache_backup.sh /etc/cron.daily ls -La /etc/cron.daily crontab -l
August 10, 201411 yr Are you certain the go file is the one on the server and not a local copy? What does the following return? cp /boot/custom/bin/cache_backup.sh /etc/cron.daily ls -La /etc/cron.daily crontab -l for a file in cron.daily to be invoked, it must be made executable. after this line in your config/go script (which you already have): cp /boot/custom/bin/cache_backup.sh /etc/cron.daily add this line: chmod +x /etc/cron.daily/cache_backup.sh
August 10, 201411 yr Are you certain the go file is the one on the server and not a local copy? What does the following return? cp /boot/custom/bin/cache_backup.sh /etc/cron.daily ls -La /etc/cron.daily crontab -l Yes go file is definately on the server. Running the above gives me: Tower login: root Linux 3.9.11p-unRAID. root@Tower:~# cp /boot/custom/bin/cache_backup.sh /etc/cron.daily root@Tower:~# ls -La /etc/cron.daily ./ ../ cache_backup.sh* logrotate* plexupdater* root@Tower:~# crontab -l # If you don't want the output of a cron job mailed to you, you have to direct # any output to /dev/null. We'll do this here since these jobs should run # properly on a newly installed system, but if they don't the average newbie # might get quite perplexed about getting strange mail every 5 minutes. :^) # # Run the hourly, daily, weekly, and monthly cron jobs. # Jobs that need different timing may be entered into the crontab as before, # but most really don't need greater granularity than this. If the exact # times of the hourly, daily, weekly, and monthly cron jobs do not suit your # needs, feel free to adjust them. # # Run hourly cron jobs at 47 minutes after the hour: 47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null # # Run daily cron jobs at 4:40 every day: 40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null # # Run weekly cron jobs at 4:30 on the first day of the week: 30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null # # Run monthly cron jobs at 4:20 on the first day of the month: 20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null # Scheduled Parity Check 0 0 28-31 * * [ $(date +%d -d tomorrow) -eq 1 ] && /root/mdcmd check 1>/dev/null 2>&1
August 10, 201411 yr for a file in cron.daily to be invoked, it must be made executable. after this line in your config/go script (which you already have): cp /boot/custom/bin/cache_backup.sh /etc/cron.daily add this line: chmod +x /etc/cron.daily/cache_backup.sh Thanks added this but still doesn't run???
Archived
This topic is now archived and is closed to further replies.