@wirezfree- Cool ! Maybe multiple requests will prompt an interest by the maintainer/developer and hopefully a feature. I didn't see a support/donate on the site.
I will check out FreeFileSync too, thanks !
Just a thought here, but could you create a simlink to the network drive and select the simlink in systemback?
@avj,
Symlinks do not work also, the destination appears to need a specific mount point & type.
I'm going to have another go at mounting via fstab.
I have all my mounts done via /etc/rc.local
like this
They work fine for everything except systemback
Subsequent tweaks have allowed me to use just names, like
nas1-syn &
nas2-wdc instead of ip address
I finally got my NAS to mount via fstab method, I used
this method, to get the NAS Share mounted, and it worked 1st time.
I then used the "
bind method" to link it also to a folder in a directory in /home/dave/ so I can easily jump to the folder.
I'm now able to select it in Systemback...
/mnt/files/systemback
((I can read/write to and from it, and see the changes on the NAS Gui))
"However", I get an error on creating a re-store point.
Restore Point Creation Failure: "There has been critical changes in the file system during this operation"
I have posted on
kendeks launchpad.
I noticed somebody else with same error from a 2 weeks ago.
I will see what response I get to the issue, and report back....
Quick update:
responses from Kendek, if I understand correctly point to file/directory permissions not being correct on NAS or mount point..?? ...
I need to investigate to see if I can find out what permissions are for USB drive & 2nd disk that work O.K
So this is what I have for access for read/write:
Code:
//nas1/systemback /media/systemback cifs credentials=/home/dave/.smbcredentials,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777 0 0
Here is the answer i received from the developer. (seems this is not supported)
Your question #271517 on Systemback changed:
https://answers.launchpad.net/systemback...ion/271517
Status: Open => Answered
Kendek proposed the following answer:
The Systemback does not save any partitions, and does not using
container files when creating the restore points (incremental backup
method). The Systemback working on a file system level, so the restore
points storage directory should handle the all permissions, without any
restrictions (like the root filesystem). If you are able to mount (under
a selectable local dir) a shared directory which transfers all file
permissions (just like a local dir), then it might work (but I do not
know, this solution is not supported).
--
If this answers your question, please go to the following page to let us
know that it is solved:
https://answers.launchpad.net/systemback...nswer_id=0
If you still need help, you can reply to this email or go to the
following page to enter your feedback:
https://answers.launchpad.net/systemback...ion/271517
You received this question notification because you asked the question.
@technomancer
The same as I received, it seems it's down to access permissions it seems on the "target" media/device.
I have retried various mount locations now to mount the NAS share to
/mnt/systemback and
/media/dave/systemback , same failure.
I have yet to investigate what the difference is between a USB device or a partition vs the NAS mount point in terms of permissions
It's a little frustrating when all other apps can access the shares without issues
I suppose having the sytemback images/file on external media is not an issue really..
If I had a house fire, or a serious flood, the NAS would be toast anyway.
Maybe I need the NAS in the shed at the bottom of the garden, "offsite backup"
