Ryan2207 Posted November 26, 2015 Share Posted November 26, 2015 Hello All I'm looking to create a backup strategy for my unraid system, i'd like to backup my usb flash drive setting and some of my data, important documents photos etc... my 2 backup destinations will be a 4 bay nas with 2tb of storage and a usb dock with 1tb what would be the best option to backup using these 2 things im looking into using crashplan over the weekend but im open to all kinds of ideas Please Share your backup experiences Kind Regards Ryan Link to comment
schford Posted November 27, 2015 Share Posted November 27, 2015 sooo I went through this myself recently and this is what I came up with,. 1 - for my documents, set up Crash Plan to auto backup the appropriate shares / files. 2 - for the flash drive I manually stop the array whenever I do a change (pretty rare) and want to back it up then I back it up before restarting. Haven't had to test 2 recovery but 1 works a treat. Stuart Link to comment
Ryan2207 Posted November 27, 2015 Author Share Posted November 27, 2015 Are you able to backup to a NAS ?, i've read crashplan doesn't have that functionality Link to comment
BrianAz Posted November 27, 2015 Share Posted November 27, 2015 I run Arq on my MacMini. I mount my TV & Movie unRAID shares and back them up to Amazon Cloud Drive Unlimited ($60/year). I have no idea how long Amazon will continue offering "Unlimited" once they see that folks have very large media collections these days, but for $5/mnth I couldn't pass it up (not to mention the year free they gave me in a promotion for something I bought). Started in early November and just crossed 1.7TB of TV shows backed up. It will take many months for sure, but I'm OK with that. Link to comment
trurl Posted November 27, 2015 Share Posted November 27, 2015 One thing you must be very careful about regarding flash backup. You must never restore a flash from a backup that has an array configuration that is not current. There has been more than one occasion where someone upgraded their parity drive and then used their old parity drive as a data drive. When they later tried to use an old backup of their flash, unRAID thought their old parity drive, now containing data, was still the parity drive and it began to overwrite that data with parity. Link to comment
Ryan2207 Posted December 15, 2015 Author Share Posted December 15, 2015 Does the dat file need to be removed as well ? Link to comment
trurl Posted December 15, 2015 Share Posted December 15, 2015 Does the dat file need to be removed as well ? config/super.dat is the array configuration I mentioned in my previous post. If it is not current then you should delete it and then you will have to reassign all your drives. Another thing that is stored in config/super.dat is the run/stop status of the array. If you make a copy with the array running and then restore that copy, unRAID will think the last shutdown was unclean when it boots up and start a correcting parity check. If you share flash over the network, then it will still be shared if you stop the array, so you can stop array, copy flash, start array. That's the way I always do it when I make any major changes. Link to comment
gundamguy Posted December 15, 2015 Share Posted December 15, 2015 I see the idea of backing up the flash come up a lot. What is the real value in backing up the flash? Backing up the super.dat is not a good idea, and everything else (not manually created by the user) should be stock. Config data for apps really shouldn't be stored on the flash, and so... I guess what I am saying is... where is the actual value in backing the flash up? What are you actually backing up of value? I can see backing up any scripts you crated for yourself (a good idea anyway, but not a reason to back up your whole flash) but that's the only thing on the flash I would think you would need to back up... Link to comment
dlandon Posted December 15, 2015 Share Posted December 15, 2015 I see the idea of backing up the flash come up a lot. What is the real value in backing up the flash? Backing up the super.dat is not a good idea, and everything else (not manually created by the user) should be stock. Config data for apps really shouldn't be stored on the flash, and so... I guess what I am saying is... where is the actual value in backing the flash up? What are you actually backing up of value? I can see backing up any scripts you crated for yourself (a good idea anyway, but not a reason to back up your whole flash) but that's the only thing on the flash I would think you would need to back up... Users, Shares, drive configuration, network, smb, nfs, afp, dockers, vms, plugins, etc. There is a lot of configured stuff to replicate and I doubt you'd be able to remember it all. Link to comment
gundamguy Posted December 15, 2015 Share Posted December 15, 2015 I see the idea of backing up the flash come up a lot. What is the real value in backing up the flash? Backing up the super.dat is not a good idea, and everything else (not manually created by the user) should be stock. Config data for apps really shouldn't be stored on the flash, and so... I guess what I am saying is... where is the actual value in backing the flash up? What are you actually backing up of value? I can see backing up any scripts you crated for yourself (a good idea anyway, but not a reason to back up your whole flash) but that's the only thing on the flash I would think you would need to back up... Users, Shares, drive configuration, network, smb, nfs, afp, dockers, vms, plugins, etc. There is a lot of configured stuff to replicate and I doubt you'd be able to remember it all. I agree with some but not all of this. Users - and SMB, NFS, and AFP share configuration, make sense. (Where is this stored on the flash and is there any risk in doing a restore job with this?) VMS - might make sense. I don't really use VMs so I don't know and can't comment. Drive Configuration - is the one that gets people in trouble... and seems like it should be backed up the good old fashioned way... (on paper...) Plugins / Docker - I don't see a ton of value in this... the config is stored elseware (or should be) so all you are backing up is the plugin file... or docker xml (Not a big user of docker so... again not 100% sure) It's a good time saver, but it's not as important as backing up other things... IMO. Link to comment
trurl Posted December 15, 2015 Share Posted December 15, 2015 I see the idea of backing up the flash come up a lot. What is the real value in backing up the flash? Backing up the super.dat is not a good idea, and everything else (not manually created by the user) should be stock. Config data for apps really shouldn't be stored on the flash, and so... I guess what I am saying is... where is the actual value in backing the flash up? What are you actually backing up of value? I can see backing up any scripts you crated for yourself (a good idea anyway, but not a reason to back up your whole flash) but that's the only thing on the flash I would think you would need to back up... Users, Shares, drive configuration, network, smb, nfs, afp, dockers, vms, plugins, etc. There is a lot of configured stuff to replicate and I doubt you'd be able to remember it all. I agree with some but not all of this. Users - and SMB, NFS, and AFP share configuration, make sense. (Where is this stored on the flash and is there any risk in doing a restore job with this?) VMS - might make sense. I don't really use VMs so I don't know and can't comment. Drive Configuration - is the one that gets people in trouble... and seems like it should be backed up the good old fashioned way... (on paper...) Plugins / Docker - I don't see a ton of value in this... the config is stored elseware (or should be) so all you are backing up is the plugin file... or docker xml (Not a big user of docker so... again not 100% sure) It's a good time saver, but it's not as important as backing up other things... IMO. Explore your flash drive sometime. Many of the files on it are text and you can see what is stored in them for yourself. Most of the things you configure in the webUI are in the config folder, or subfolders of that. While the docker and plugin working data are stored elsewhere, the settings that tell them where that data is are on the flash. Sometimes docker settings can be complicated and need to be just right when you want multiple dockers working with the same data. Having said all that, I also think it is a good idea to be able to set it all up from scratch if need be. I think there are a lot of users with a lot of crud accumulated, some of which can cause problems if it's not cleared out, so you should know how to either do it over, or know what should be there and what shouldn't. Link to comment
dlandon Posted December 15, 2015 Share Posted December 15, 2015 I see the idea of backing up the flash come up a lot. What is the real value in backing up the flash? Backing up the super.dat is not a good idea, and everything else (not manually created by the user) should be stock. Config data for apps really shouldn't be stored on the flash, and so... I guess what I am saying is... where is the actual value in backing the flash up? What are you actually backing up of value? I can see backing up any scripts you crated for yourself (a good idea anyway, but not a reason to back up your whole flash) but that's the only thing on the flash I would think you would need to back up... Users, Shares, drive configuration, network, smb, nfs, afp, dockers, vms, plugins, etc. There is a lot of configured stuff to replicate and I doubt you'd be able to remember it all. I agree with some but not all of this. Users - and SMB, NFS, and AFP share configuration, make sense. (Where is this stored on the flash and is there any risk in doing a restore job with this?) VMS - might make sense. I don't really use VMs so I don't know and can't comment. Drive Configuration - is the one that gets people in trouble... and seems like it should be backed up the good old fashioned way... (on paper...) Plugins / Docker - I don't see a ton of value in this... the config is stored elseware (or should be) so all you are backing up is the plugin file... or docker xml (Not a big user of docker so... again not 100% sure) It's a good time saver, but it's not as important as backing up other things... IMO. Dockers, Plugins, and other configuration settings are stored on the flash. It's not just copies of the plugins. Having a flash backup copy is a pretty good idea. Especially if the flash goes bad or an upgrade goes bad. I've had this happen and the backup makes it easy to get back to where you were. I have a spare flash drive set up in unassigned devices that I plugin and the backup is done automatically. Very easy and painless. Other than backing up important or unrecoverable files, this is a key backup to have. Link to comment
gundamguy Posted December 15, 2015 Share Posted December 15, 2015 Explore your flash drive sometime. Many of the files on it are text and you can see what is stored in them for yourself. Most of the things you configure in the webUI are in the config folder, or subfolders of that. While the docker and plugin working data are stored elsewhere, the settings that tell them where that data is are on the flash. Sometimes docker settings can be complicated and need to be just right when you want multiple dockers working with the same data. Having said all that, I also think it is a good idea to be able to set it all up from scratch if need be. I think there are a lot of users with a lot of crud accumulated, some of which can cause problems if it's not cleared out, so you should know how to either do it over, or know what should be there and what shouldn't. I'll have to do that. My intention is to figure out exactly what should be backed up and make a piece meal backup that has minimal fluff or at worse removes the risk of a user error resulting in data loss. Good to know most of it's in plain text. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.