Mattaton Posted January 9 Share Posted January 9 9 minutes ago, ich777 said: Can you describe a bit further what you are trying to achieve? You can pass over TZ as a variable to the container (which it should do by default), I tested this back with 6.10 I think and it was working fine with the correct timezone. Depends on where you put those files, they should all go into /luckybackup in the container and not in /root (if you are running luckyBackup as root). So, I can just add in a TZ var to the ENV setup and that will do it, or do I need to do the .profile avenue that @cybrnook described? Quote Link to comment
cybrnook Posted January 9 Share Posted January 9 1 minute ago, Mattaton said: So, I can just add in a TZ var to the ENV setup and that will do it, or do I need to do the .profile avenue that @cybrnook described? @Mattaton Try and and see if it works Log into docker console (you will be root), and execute: su - luckybackup touch .profile echo "export TZ=America/New_York" > .profile Then restart your container and check the "date" commands again. Then maybe test a simple scheulded backup and see if it kicks off when you want it to. 1 Quote Link to comment
Mattaton Posted January 9 Share Posted January 9 (edited) 5 minutes ago, cybrnook said: @Mattaton Try and and see if it works Log into docker console (you will be root), and execute: su - luckybackup touch .profile echo "export TZ=America/New_York" > .profile Then restart your container and check the "date" commands again. Then maybe test a simple scheulded backup and see if it kicks off when you want it to. I tried just adding a TZ var to the ENV settings. That did not work. Date command still returns in CET. Created the .profile as you described and it returned the time in EST, albeit in a different format and in 24-hour syntax (as yours did). root@d841cef0c6d7:/# date Tue 09 Jan 2024 03:28:03 PM EST root@d841cef0c6d7:/# su - luckybackup luckybackup@d841cef0c6d7:~$ date Tue Jan 9 15:28:12 EST 2024 Edited January 9 by Mattaton Quote Link to comment
cybrnook Posted January 9 Share Posted January 9 1 minute ago, Mattaton said: Created the .profile as you described and it returned the time in EST, albeit in a different format and in 24-hour syntax. root@d841cef0c6d7:/# date Tue 09 Jan 2024 03:28:03 PM EST root@d841cef0c6d7:/# su - luckybackup luckybackup@d841cef0c6d7:~$ date Tue Jan 9 15:28:12 EST 2024 Good! Can you setup a simple backup job to run, say in 5 min and see if it kicks off correctly? 1 Quote Link to comment
Mattaton Posted January 9 Share Posted January 9 10 minutes ago, cybrnook said: Good! Can you setup a simple backup job to run, say in 5 min and see if it kicks off correctly? Just ran a test and it seems to be working! Thanks for the help with this! And I would think anything in the luckybackup folder is persistent, correct? Quote Link to comment
cybrnook Posted January 9 Share Posted January 9 1 minute ago, Mattaton said: Just ran a test and it seems to be working! Thanks for the help with this! And I would think anything in the luckybackup folder is persistent, correct? Yes, I think so. That's where @ich777 has been pointing all users to go for persistent changes (like keys). This should be no different. 1 Quote Link to comment
ich777 Posted January 9 Share Posted January 9 2 minutes ago, cybrnook said: Yes, I think so. That's where @ich777 has been pointing all users to go for persistent changes (like keys). This should be no different. Have you yet tried to create a Variable in the Docker template itself with the Key: TZ and as Value: America/New_York This should basically do the same system wide. Quote Link to comment
cybrnook Posted January 9 Share Posted January 9 (edited) 25 minutes ago, ich777 said: Have you yet tried to create a Variable in the Docker template itself with the Key: TZ and as Value: America/New_York This should basically do the same system wide. That didn't work (just to calrify, the "root" user in the container is fine, it's the "luckybackup" user that is running as CET. That seems the be the main app user within the container, where cron is being used.): Edited January 9 by cybrnook Quote Link to comment
Mattaton Posted January 9 Share Posted January 9 5 minutes ago, cybrnook said: That didn't work: Same. Didn't work when I tried either. Quote Link to comment
ich777 Posted January 9 Share Posted January 9 29 minutes ago, cybrnook said: just to calrify, the "root" user in the container is fine, it's the "luckybackup" user that is running as CET. That seems the be the main app user within the container, where cron is being used This should not matter since it‘s a environment variable and it is available for all users, I‘ll look into that tomorrow, it‘s getting late over here. 1 Quote Link to comment
cybrnook Posted January 9 Share Posted January 9 19 minutes ago, ich777 said: This should not matter since it‘s a environment variable and it is available for all users, I‘ll look into that tomorrow, it‘s getting late over here. Schlaf gut 🙂 (Sleep well) Quote Link to comment
Mattaton Posted January 10 Share Posted January 10 Update on the timezone scheduling... I have the cron for my main profile (daily-5am) set to run at 5am, which it did NOT. I checked the timezone and it still checks out as EST. So, we'll see if it runs at 11am and the 6-hour delay issue remains. 0 5 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1 Before yesterday, I had this cron job set to 0 0 * * * and it would run at 6am (6 hours later). With the timezone fix, I would think this should have run at 5am when set to 0 5 * * *. You guys see anything I'm doing wrong? Quote Link to comment
cybrnook Posted January 10 Share Posted January 10 2 hours ago, Mattaton said: Update on the timezone scheduling... I have the cron for my main profile (daily-5am) set to run at 5am, which it did NOT. I checked the timezone and it still checks out as EST. So, we'll see if it runs at 11am and the 6-hour delay issue remains. 0 5 * * * /usr/bin/luckybackup -c --no-questions --skip-critical /root/.luckyBackup/profiles/ daily-5am.profile > /root/.luckyBackup/logs/daily-5am-LastCronLog.log 2>&1 Before yesterday, I had this cron job set to 0 0 * * * and it would run at 6am (6 hours later). With the timezone fix, I would think this should have run at 5am when set to 0 5 * * *. You guys see anything I'm doing wrong? @Mattaton let's continue in the support thread. Quote Link to comment
WarHawk8080 Posted January 28 Share Posted January 28 (edited) I have been using rsync to backup my audiobooks from my UnRaid box to a 2nd smaller TrueNAS Scale box...was thinking about this...saw the validate command on luckybackup to show Would something like this as a cron? rsync -aqu --protect-args -chown=warhawk:warhawk /mnt/user/appdata [email protected]:/mnt/optimus/NAS/WarHawk/MOBIUS.DOCKER.BACKUP The -a is "archive mode" which is the command "equivalent" to -rlptgoD The -q quiet (so it doesn't output anything)...just does it The -u updates (allows rsync to skip files that are still new in the destination directory) don't know what the --protect-args is...is that the same as -p or preserve permissions? The -chown just makes sure it has the same permissions on my target drive as the "user:group" I am backing up to (otherwise my user has a directory with a bunch of "nobody:users" files/directories in them. Of course I ran the first command like this the first time to watch all the awesome text go by to ensure it was actually going to the correct location. rsync -avhP /mnt/user/appdata [email protected]:/mnt/optimus/NAS/WarHawk/MOBIUS.DOCKER.BACKUP Since I followed the howto and installed the /root/.ssh/id_rsa it allows passwordless SSH login and instant upload/backup to my 2nd box Edited January 28 by WarHawk8080 Quote Link to comment
ich777 Posted January 28 Share Posted January 28 14 hours ago, WarHawk8080 said: Since I followed the howto and installed the /root/.ssh/id_rsa it allows passwordless SSH login and instant upload/backup to my 2nd box Please don't, please use /luckybackup/.ssh/id_rsa It should always point to /luckybackup and not to /root inside the container! 14 hours ago, WarHawk8080 said: --protect-args is...is that the same as -p or preserve permissions? No, that is not the same, --protect-args is used when you have special characters or I think even spaces in your paths and you don't want the shell to mess with that when passed over to rsync. Quote Link to comment
DontWorryScro Posted April 24 Share Posted April 24 (edited) I followed the video guide posted at the top of this thread and it had the docker container running on the source machine. Is a backup machine meant to be pulling from the source machine instead of the source machine pushing to the destination machine? Does it matter? Also why synchronize instead of backup? Edited April 25 by DontWorryScro Quote Link to comment
DontWorryScro Posted April 25 Share Posted April 25 (edited) On 3/17/2022 at 3:16 AM, ich777 said: Please use the directory /luckybackup/.ssh/ for your id_rsa. im not as adept as others. Can you tell me how to take the id_rsa from the root dir that was explained in the guide and copy/move it to where ever this is? And how to adjust the path in luckybackup to find the new location I rewatched the video and any instance of typing root in cli i replaced with luckybackup but all things being equal, in the end, i just saw this when i navigated to the newly created luckybackup directory for the key. Looks to be empty inside. what i do wrong? I was able to rightclick in the empty space to give me the option to show hidden files which did in fact reveal to me the id_rsa files i had created. but selecting them and attempting the backup popped some weird password request window in the VNC. Edited April 25 by DontWorryScro Quote Link to comment
ich777 Posted April 25 Share Posted April 25 6 hours ago, DontWorryScro said: Is a backup machine meant to be pulling from the source machine instead of the source machine pushing to the destination machine? Does it matter? You can do it either way and it doesn't matter much. I'm more comfortable pulling it from the source machine to the destination since it feels a bit more safe to me since you can write a script that is running on server start that starts the backup, shuts down the machine automatically if needed and if this machine is only powered on for a backup. 5 hours ago, DontWorryScro said: Can you tell me how to take the id_rsa from the root dir that was explained in the guide and copy/move it to where ever this is? Please don't use the root directory, you always have to use the id_rsa from the /luckybackup/.ssh directory not root because otherwise it will be wiped on a container update. 5 hours ago, DontWorryScro said: I rewatched the video and any instance of typing root in cli i replaced with luckybackup but all things being equal, in the end, i just saw this when i navigated to the newly created luckybackup directory for the key. Looks to be empty inside. what i do wrong? Please post a screenshot from your Docker template. 5 hours ago, DontWorryScro said: but selecting them and attempting the backup popped some weird password request window in the VNC. Then you selected the wrong keys. BTW You don't have to create new keys, please use the existing ones which are located in /luckybackup/.ssh since they are individually created for each installation and as said above, please don't use the keys from /root/.ssh Quote Link to comment
DontWorryScro Posted April 25 Share Posted April 25 (edited) 9 hours ago, ich777 said: You can do it either way and it doesn't matter much. I'm more comfortable pulling it from the source machine to the destination since it feels a bit more safe to me since you can write a script that is running on server start that starts the backup, shuts down the machine automatically if needed and if this machine is only powered on for a backup. Please don't use the root directory, you always have to use the id_rsa from the /luckybackup/.ssh directory not root because otherwise it will be wiped on a container update. Please post a screenshot from your Docker template. Then you selected the wrong keys. BTW You don't have to create new keys, please use the existing ones which are located in /luckybackup/.ssh since they are individually created for each installation and as said above, please don't use the keys from /root/.ssh Oh it'd sure be amazing to do that turn on -> backup -> turn back to off move. Is there a guide on that anywhere? Also what container update in regards to the root vs luckybackup directory? The container is running on my source machine. I dont have a LuckyBackup docker container running on my destination machine where the id_rsa is kept. I must be brain farting on this somewhere along the line. Here is a screencap of my docker container config Edited April 25 by DontWorryScro Quote Link to comment
ich777 Posted April 25 Share Posted April 25 16 minutes ago, DontWorryScro said: Is there a guide on that anywhere? Please see here: I think this is a pretty step by step tutorial. Quote Link to comment
justintas Posted May 17 Share Posted May 17 On 1/2/2024 at 4:36 AM, Mattaton said: Thanks. I just turned that on. I'll see what happens tonight. Did you ever get the schedule to work ? Manual works fine but I'm having similar problems with scheduler and going in circles trying to work out why it won't work. My schedule is as follows: And My docker setup as well: Any pointers appreciated. Quote Link to comment
ich777 Posted May 22 Share Posted May 22 On 5/17/2024 at 2:02 AM, justintas said: Any pointers appreciated. Solved here: Quote Link to comment
Mattaton Posted August 10 Share Posted August 10 Had to stop using luckyBackup as it appears to change the owner of directories. I run immich on my server and I had luckyBackup syncing the photos to another server. But intermittently, I'd have photo auto-backup from the app fail and I'd find that all the directories in the immich folder had the owner changed to UNKNOWN. I'd chown the owner back to nobody and auto-backup would start working again. Then a couple days later I'd realize photo backups weren't working again and sure enough the owner was switched back to UNKNOWN again. So, given that luckyBackup had direct access to the share, it seemed like the obvious culprit. So I looked at other folders that luckyBackup was backing up and sure enough, all the owners were set to UNKNOWN. In those cases it wasn't breaking anything because what it was backing up was already in a backup folder on the local server and LB was only syncing those backups to another server. With Immich, it was affecting the live folder. Is this a known issue? Quote Link to comment
ich777 Posted August 11 Share Posted August 11 15 hours ago, Mattaton said: So, given that luckyBackup had direct access to the share, it seemed like the obvious culprit. So I looked at other folders that luckyBackup was backing up and sure enough, all the owners were set to UNKNOWN. In those cases it wasn't breaking anything because what it was backing up was already in a backup folder on the local server and LB was only syncing those backups to another server. With Immich, it was affecting the live folder. LuckyBackup won't change the permissions or files in the source directory at all by default (it shouldn't do that in the destination either). Can you please share your Settings how you set up the Backup task? I can only think of a configuration issue. 16 hours ago, Mattaton said: Then a couple days later I'd realize photo backups weren't working again and sure enough the owner was switched back to UNKNOWN again. Are you really sure that nothing else does change the permissions, I personally don't run Immich so my knowledge about that container is limited but maybe there is a setting where you can define the user? 1 Quote Link to comment
Mattaton Posted August 11 Share Posted August 11 6 hours ago, ich777 said: LuckyBackup won't change the permissions or files in the source directory at all by default (it shouldn't do that in the destination either). Can you please share your Settings how you set up the Backup task? I can only think of a configuration issue. Are you really sure that nothing else does change the permissions, I personally don't run Immich so my knowledge about that container is limited but maybe there is a setting where you can define the user? Agreed. I am definitely not sure something else isn't going on. Immich has PUID and PGID settings, but I have doublechecked with the devs and I have them set correctly for unRAID. 99 and 100, respectively. But still, I had other folders unrelated to Immich that were also synced using LuckyBackup that also had all the owners set to UNKNOWN. I've been trying to think of what else might be doing this as it also makes little sense to me that LuckyBackup would alter the owner. There is some database backup software that has access to my database backups, but it doesn't have access to the Immich stuff. So far the only thing I can come up with that has access to all these things is LuckyBackup. I had LB disabled last night and the proper owner was retained. I will watch it over the next few days and see if it changes with LB disabled. Other than screenshots, is there a better way to share my LB settings with you? Thanks! Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.