![]() ![]() In the end I removed the symlink to /opt and added links to the specific subfolders in /opt that I really wanted to back up. Packing opt/vagrant/embedded/lib/libcrypto.so.1.0.0Īdd me to the list of people that can't grok duplicacy excludes patterns :) Packed opt/vagrant/embedded/lib/libcrypto.so (2588980) Packing opt/vagrant/embedded/lib/libcrypto.so Packed opt/vagrant/embedded/include/openssl/obj_mac.h (175657) ![]() Packed opt/vagrant/embedded/include/openssl/modes.h (8260) Packing opt/vagrant/embedded/include/yaml.h Packed opt/vagrant/embedded/include/lzma.h (9276) Packing opt/vagrant/embedded/include/lzma.h Packing opt/vagrant/embedded/gems/gems/vagrant-share-1.1.6/locales/en.yml Packed opt/vagrant/embedded/gems/gems/vagrant-share-1.1.6/localbin/proxy_windows_amd64.exe (12208128) Packing opt/vagrant/embedded/gems/gems/vagrant-share-1.1.6/localbin/proxy_windows_amd64.exe Skipped 15156 files from previous incomplete backup I really don't need to backup vagrant so my first try at a workaround will be excluding that.This failing chunk is not the first chunk to be uploaded, there is at least one before.Ok, edited results of running 'duplicacy -d backup' for this backup set below. The only thing that I changed was the backup id - ssh key and password I kept the same.Īnyway, will investigate more tomorrow, thanks for the prompt answer. I makes little sense to me that backing up different files would cause a permissions issue. The thing is, I've already run one backup from this machine repeatedly, its just a different backup set. It might be the first uploaded chunk, I'll check that too. Could this be the first chunk to be uploaded by this backup run because all previous chunks already existed on the server? ![]() However, I think this should be a permission issue on the server. If you run with -d option like duplicacy -d backup it should give you the file that the failed chunk came from by searching for those "Packed file" messages. So it seems unlikely to be a simple permissions issue on the server, which has me wondering what the problem file is that that failed chunk came from - is there a way to find out? It's worked well, current repo size is 1.1tb. The chroot on the server is in a zfs mirror. duplicacy is running as root on the client and sftp'ing as duplicacy user on the server. There is a duplicacy user setup on the server in a chroot that's only allowed to do sftp. This is duplicacy linux cli 2.09 transferring files via sftp over a gigabit wired connection. Incomplete snapshot saved to /duplicacy/.duplicacy/incomplete I'm now adding to the repo from a another linux box, a backup of the home folder has worked well but I've added a second backup of some more extraneous stuff (/etc, /root and /opt) and its failed twice with this error: All went well, deduplication worked very well. I've successfully done multiple backups from 2 machines (one osx, one linux) to my ubuntu home server via sftp and I've added to the repo from other disks on the server. All issues sftp "Permission denied" - I need debugging help! ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |