1/8/2024 0 Comments Crashplan for qnapThese tags help give a resource to our Product team to gauge customer interest in various features or improvements. This might not come in time to help smooth out your experience with your particular setup, but I can mark this ticket with a feature request tag. That is excellent to hear that you have devised a solution which fits your needs! This is what CrashPlan support replied when I told them about my workaround: This script needs to be run at startup as root, so I call it from cron ( sudo crontab -u root /home/amedee/bin/test_cifs_shares.sh.The actual startup script itself takes care of checking if it has already started (or stopped). Starting (or stopping) the service if it is already started (or stopped) is very much ok.I can add or remove shares without needing to modify the script, I only need to edit file_list.txt – even while the script is still running.They all have to be present, if even only one of them is missing or can’t be reached, then the service must be stopped. ![]() file_list.txt contains a list of testfiles on different shares that I want to check.#!/bin/bashįile_list="/home/amedee/bin/file_list.txt" So I have to resort to checking if a file exists. However when the network connection just drops for any reason, then inotifywait doesn’t get an event. I first considered using inotifywait, which listens to filesystem events like modifying or deleting files, or unmount. It may not be the cleanest solution but I’m happy with it. This workaround works, and is good enough for me. As soon as the file becomes available again, then the CrashPlan service is started. No problem, Nathaniel! I found a workaround: a shell script that checks if a certain marker file on the network share exists, and if it doesn’t, then the script stops the CrashPlan service, which will prevent CrashPlan from scanning the file selection. Nathaniel, Technical Support Agent, Code42 The only solution would be for you to engineer your network so as not to interrupt the connection. This is an unavoidable negative consequence of mapping a network drive to a location which you’ve included in CrashPlan’s file selection. There’s no way around this, aside from ensuring that you either keep a stable connection. The program needs to know what (if anything) is still there, and is designed firmly to track those types of changes, not to give up and stop monitoring the locations within its file selection. CrashPlan will not shut down upon receiving a drive detachment or attachment hardware event. A hardware event pointing out that a drive within the /home/amedee/Multimedia/ file path has changed its connection status will trigger a scan. Since the drive detaching will send a hardware event from the OS to CrashPlan, CrashPlan will see that that hardware event lies within its file selection – due to the fact that you mapped your network drives into a location which you’ve configured CrashPlan to watch. Your drives need to retain a stable connection in order to avoid the necessity of the software to run a new scan when it sees the drives attached to the device (so long as they’re within the file selection) detach and reattach. This is in inherent drawback to including network drives within your file selection. ![]() If a location within CrashPlan’s file selection is detached from the host machine, then the program will need to rescan the selection. I do not believe that this scenario can be avoided with this product – at least not in conjunction with your desired setup. I contacted CrashPlan support about this issue, and this was their reply: It doesn’t have to upload all files again, because Crashplan doesn’t purge the files on it’s cloud immediately, but the file verification still happens. As soon as the shares come back online, the files are backed up again. There’s only one thing that I had to fix: if Crashplan runs when the shares aren’t mounted, then it thinks that the directories are empty, and it will delete the backup on the cloud storage. ![]() I made 3 different backup sets, one for each of the shares. Now that I have mounted most of the network shares on my local filesystem, I can just run the backup on my pc. So I gave up, and I didn’t have a backup for almost 4 years. After 2018, none of the solutions to run a backup on the NAS itself stopped working. There is a qpkg package for CrashPlan, and there are lots of posts on the QNAP support forum. It works very well on Linux, Windows and Mac, but it was always a bit fickle on my QNAP NAS. In 2018 they stopped their Home solution, so I switched to their Business plan.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |