Wicus

New Members
  • Content Count

    14
  • Joined

  • Last visited

About Wicus

  • Rank
    Member

Recent Profile Visitors

276 profile views
  1. It has finally synced between the PC & Pi and reflects no errors or warnings. I then validated the data on the PC with an original copy via "diff -R'. All checked out. The only thing peculiar I have noticed so far, is a directory that has been mangled from "C***Connect" to "C894EM~I" ... Just to recap, the data copy from drive to drive over USB3 took an entire evening. The syncing thereafter, basically only indexing on the PI (as the data was already on the Pi), took more than a week over a Gigabit LAN. The 'diff -R' check, between two drives on the PC, took about 5 hours. Can anyone please elaborate on their experience with such an initial amount of data to sync ? (Especially as we have interest in syncing multiple 8TB shares) Are these time frames the norm ? Is there anything one can do to speed up the inital sync with a new device when such an amount of data is involved ? For example, can the original data be copied with specific Resilio Sync "database files" (or edited version) to the target which would speed up the initial sync to a few hours than weeks?
  2. Only 1 of the 4 cores on the PI is in the 70 - 100% range for about 2 seconds, before repeating on the next core, with the remaining 3 cores then at around 0.7%. The drives holding the data share is each mounted during boot via /etc/fstab : - PARTUUID="ID of drive" /SYNC ext4 defaults 0 2 The shared folders were then also set as follow: $ sudo chown -R rslync:rslsync /SYNC $ sudo chmod -R 775 /SYNC ** This was reapplied on the PI once the external drive was reconnected after the manual transfer was completed via the PC ** The /var/lib/resilio-sync folder on the PI currently holds 1.9G of data, versus 1.1G on the Ubuntu machine. In the/var/lib/resilio-sync/sync.log I am seeing quite a few " ... error: "initial recheck" (1)" messages and believe this is due to the indexing being too slow ... ? In the interim, I have disabled - Use relay server when required - Use tracker server - Search LAN and enabled - Use predefined hosts -> with the peer's IP:port configured I believe this might have resulted in a minor improvement, though only about 255GB of data has synced in the last 24 hrs, being only indexing completing on the PI. Is this the expected performance using a PI, or is there reason for concern ?
  3. From my doodle notes, I currently understand that only 16 910 of 302 782 files has been synced between the two devices over 3 days. although no files were actually transitioned over the network. Using a PI as an endpoint seems like a truly bad idee ...
  4. I have an Ubuntu 4.13.0-32-generic PC configured with Resilio Sync 2.5.12(1191) that has a 1.6TB folder share. The share was copied to an external 2TB USB 3.0 hard disc which was then connected to a Raspberry Pi 2. The Pi is running Raspbian 4.9.59-v7+ with Resilio Sync 2.5.12(1191) armhf. A NetGear R6300 connects the two devices via CAT6 cabling. Though the PC's time is correct, even prior to Resilio Sync's installation, Sync is reflecting the last sync on Jan 1 1970 ... Though "Lan_Encrypt_Data" has been set to FALSE on both machines, the Pi has never reflected Receiving and synchronization more than 0% for about a day and a half. In addition, the Ubuntu machine's history reflects no activity for the last 14 hours, though the PI's history continuously states "Ubuntu-PC added file... " with numerous "Failed to download ... - initial recheck" info messages. Is this normal initial behavior ? - Last synced date & time on PC share being Jan 1, 1970 10:00AM - Sync indication on the PI at 0% regardless of the time and number of files already synced. Would it be advisable not to write or modify files on the PI before the initial sync has completed ? Is there anything additional/alternate that could be done to speed things up ? .. or is there serious issues with my approach at initial syncing ?
  5. When I follow the exact same procedure to do a completely new installation of Sync onto a completely new Raspbian (Jessy) installation, it works 100% fine on a Raspberry PI 2, though fails as follows on a Raspberry PI 1: Setting up btsync (2.3.8-1) ... Job for btsync.service failed. See 'systemctl status btsync.service' and 'journalctl -xn' for details. invoke-rc.d: initscript btsync, action "start" failed. dpkg: error processing package btsync (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for systemd (215-17+deb8u3) ... Errors were encountered while processing: btsync E: Sub-process /usr/bin/dpkg returned an error code (1) "systemctl status btsync.service" states: ‚óŹ btsync.service - BitTorrent Sync service Loaded: loaded (/lib/systemd/system/btsync.service; enabled) Active: failed (Result: start-limit) since Thu 2016-07-14 02:16:39 AEST; 10min ago Docs: http://help.getsync.com/ Process: 2005 ExecStart=/usr/bin/btsync --config /etc/btsync/config.json (code=killed, signal=ILL) Process: 2002 ExecStartPre=/bin/chown -R btsync:btsync /var/run/btsync (code=exited, status=0/SUCCESS) Process: 1999 ExecStartPre=/bin/mkdir -p /var/run/btsync (code=exited, status=0/SUCCESS) Jul 14 02:16:38 SYNC_Slave_01 systemd[1]: Unit btsync.service entered failed state. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: btsync.service holdoff time over, scheduling restart. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Stopping BitTorrent Sync service... Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Starting BitTorrent Sync service... Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: btsync.service start request repeated too quickly, refusing to start. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Failed to start BitTorrent Sync service. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Unit btsync.service entered failed state. " journalctl -xn" states: -- Logs begin at Thu 2016-07-14 01:56:34 AEST, end at Thu 2016-07-14 02:17:01 AEST. -- Jul 14 02:16:38 SYNC_Slave_01 systemd[1]: Unit btsync.service entered failed state. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: btsync.service holdoff time over, scheduling restart. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Stopping BitTorrent Sync service... -- Subject: Unit btsync.service has begun shutting down -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit btsync.service has begun shutting down. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Starting BitTorrent Sync service... -- Subject: Unit btsync.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit btsync.service has begun starting up. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: btsync.service start request repeated too quickly, refusing to start. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Failed to start BitTorrent Sync service. -- Subject: Unit btsync.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit btsync.service has failed. -- -- The result is failed. Jul 14 02:16:39 SYNC_Slave_01 systemd[1]: Unit btsync.service entered failed state. Jul 14 02:17:01 SYNC_Slave_01 CRON[2007]: pam_unix(cron:session): session opened for user root by (uid=0) Jul 14 02:17:01 SYNC_Slave_01 CRON[2011]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Jul 14 02:17:01 SYNC_Slave_01 CRON[2007]: pam_unix(cron:session): session closed for user root Should I remove the SD card from the PI 1 and run it on the PI 2, it works! Returning the SD card to the PI 1 and the problem persists... Both PIs use each their own 5V 2A PSU, 8GB SANDISK SD Card, with 2016-03-18-raspbian-jessie-lite.img "uname -r" on the PI 1 states: 4.4.13+ "uname -r" on the PI 2 states: 4.4.13-v7+ I'm unfortunately lost at troubleshooting this. Any aid will be greatly appreciated. Thanks
  6. We ran into CryptoWall yesterday due to an unsecure laptop, which caused havoc on a corporate network share. However, this has me ponding if Sync's Archive feature would be CryptoWall proof ? Providing the same "protection" again file changes as found on DropBox's file versioning, Time Machine or Snapshot feature. Is there any hope ?
  7. Thanks for the reply. However, should one copy 1TB of data from one share to another and then remove a file or two on the slave share, whilst Sync is still indexing, would Syn re-write the deleted files to the slave or delete them from the Master ? Note that Indexing seems to take about 2 or 3 days on 1TB of data.
  8. jalcide, I'm experiencing exactly the same results on the same setup. Have you followed the following recommendations ? I did and unfortunately no improvements. Would you mind pm'ing me in regard to the alternate solution you're currently using ?
  9. Thanks for responding GreatMarko. Though I did follow all the recommendations and verification of settings, I still cannot get more than 8MBps. What transfer speeds would you normally obtain on a pure GigaBit LAN setup ?
  10. I believe your to stay stuck in the dark, as I am. http://forum.bittorrent.com/topic/39819-gigabit-lan-sync-speed-slow/ http://forum.bittorrent.com/topic/39824-large-sync-best-practise/
  11. That was only until I decided to rather copy directly from the source to the destination, and re-start the sync. Now I'm only getting between 39 to 42.6 Kbps and Sync doesn't notice the newly added files even after disconnecting an re-sharing Only because AFTER 4 days, only 411GB of 711GB was synced ... whereas copying directly via USB took but 2 hours. What's the deal BitTorrent ?
  12. There is a difference, related to the direction of the traffic, over your router: Inbound (NAT) Enable uPnP on your router & in your Sync preferences, if you do not wish to do this manually 1. the "listening port" needs to be forwarded from your router to your machine Outbound (Usually only on hardware type firewalls, as home router setups normally allows all traffic outbound) 2. Ports 3838 and 3000 needs to be allowed outbound on your router. From titbits I've picked up over the forum, it be best to allow both UDP & TCP.
  13. What is the best practice when trying to sync a large folder? 1. Can the "master copy" be copied to the "slave" and then simply referencing during the sync setup at the slave? 2. Also, should one have started a sync already, would it be wise to stop the sync, copy files from the "master" to the "slave" and then simply restart the sync to speed-up the initial transfer?
  14. Origionally posted this query in the BitTorrent Client section, as opposed to the BitTorrent Sync area. Can only hope I won't be flamed to harshly ... I'm getting the following Sync speeds on a GigaBit LAN Min 1.6 MBps Max 6.0 MBps Avg 2.3 - 3.8 MBps Would I be totally off-topic expecting around 125 MBps? (when there is no other traffic on the LAN) Specs: 2x i7 8GB 256SSD Windows 8.1 Laptops running Sync v 2.0.128(36) connected via CAT6 cabling to a NetGear R6300v2 NoteBook 1 - 10.17.0.111 NoteBook 2 - 10.17.0.112 Sync Settings uPnP port mapping enabled Receiving & Sending rates NOT enabled lan_encrypt_data false rate_limit_local_peers false