P3R wrote:Steerpike wrote:I then relocated NAS-2 to my office in CA, and reconfigured the RTRR job to work with this new address (but no actual files were transferred after this since everything was 'seeded' already);...
Which tells us that you didn't have the option
Check file contents ticked. Because had you used that, RTRR should have found the difference and automatically updated the file for you.
Please note that the above isn't criticism, just an observation that
Check file contents would automatically have corrected the corrupt file. However depending on the available bandwidth, time and volume of data,
Check file contents may not be practically usable in all applications.
i was actually planning to do a factory reset sometime soon once a more stable firmware comes.
so if source had already previous backed up to destination, but later i accumulates just a few new files i wanted to rtrr. Would i need to enable check file contents? Or would leaving that disabled be fine for my purposes ?
Because previously i did in this order
1. NAS to NAS, source to destination
2. RTRR, source to destination, with verify file enabled (i'm assuming all it did was check if file the same, if it is, don't transfer? that said it still took a long time to complete
)
So if source had a bunch of new files (not replacements for existing ones that are already on destination), would it be okay to leave verify files disabled ?
rtrr p30.jpg
on side note, you can't just simply rtrr now, without setting it into scheduled or real time mode. In disabled it's completely disabled. Even the icon for run task refuses to run. But there is a run now toggle from the pull down :/ Looking further apparently have to schedule and run now. guess they err on the side of caution by not simply allowing you to click run task if it's set to disabled in here.
rtrr p31.jpg
rtrr p32.jpg
but anyway what i'm trying to get at is, since the files i had prior added already was verified, i rather avoid verifying them again, as their file name that it's already at destination would already suffice if only so it knows not to delete them or add a copy of the file at destination based on folder/file name alone. Then only the new file transferred would verify it's contents to ensure it transfers over without issues. Or is the transfer process already solid in not coughing up a corrupt file on the other end aka destination with verify setting disabled?
by the way got rtrr running now with verify disabled. I also disabled ssh seeing as it's done locally and it's not port forwarded over to the internet anyway. Anyway
performance is excellent at 100 MB/s on average. It was probably either encrypted transfer or the verify contents which tanked the performance in prior backups.
but what concerns me is the roughly 1000+ backed up files. Because the only new additional files i added were not that many
... Also is this a bug that time left and time remaining to match ?
synchronizing also not the same
rtrr p33.jpg
Would it be possible for the job log for after rtrr is completed to show just which files were backed up (as in not skipped) ? cause right all i know is it skipped some, but backed up a 1000+ things of which i'm not sure what
gonna be hard to self verify seeing as my contents have so many sub folders and pathings like a maze
*update
RTRR completed in 8 hours by not verifying content and encryption transfer disabled. Also data already previously already been RTRR to the destination.
anyway it says 2tb roughly was updated, but the total size for the data rtrr was 6tb. I was only expecting the updated to be less than 10gb, not 2tb... as there was only a few additional files added recently. Trying to check logs did nothing because all it told me during the rtrr was number of files skipped and files backed up, and the total amount of the whole dataset being processed. When the whole RTRR completed the logs was very basic and doesn't tell you indepth which folders/sub folders/files exactly were newly successfully backed up (and not skipped due to an existing file already at destination). So i'll need to go filestation for destination server, to delete and then run rtrr again but using "verify contents". i did a rough check and did not see any duplicates or errors, but i need some certainty that it copied exactly... hence why i need to rtrr again from scratch this time
rtrr p35.jpg
For future subsequent rtrr i'll have to use verify contents
*update
doing rtrr from scratch with verify contents enabled. but encryption disabled (since doing over local network so doubt i need it). 101 MB/S ETA 16 or so hours to backup 6.6 TB worth of data, very nice
rtrr p36.jpg
