neosheo

I have 6 devices that i rsync to a central location to back them up. Ive been using ssh as the -e option. Problem is i use public key with passphrases, meaning to backup all six i need to go to each device and run the backup script. Since i typically backup /etc, /home, and /root this means entering sudo and the ssh passphrase 3x for each device.

I would much prefer a script that runs on back storage device that can pull the data from each device without having to use ssh (encryption is not necessary since all traffic is either local or going through a vpn connection).

I could then put this script in root's crontab or make it a systemd service running as root.

But i dont know how i can remote sync without ssh

Ok i have a 5TB usb hard drive that is mostly used for weekly backups of my system. It is hooked to a raspberry pi and has an exfat file system and used as a samba share.

But i need to occasionally unplug it and connect it directly to some other machines for 2 reasons.

1. For use with steam on linux (i store my games on it)

2. For use with obs on windows (i do some screen recording and need to be able to save the output to the drive)

Here's the dilemma. Games that require proton will not launch from an exfat drive (trust me i've tried all the "hacks" and cant make it happen). So i plan to reformat the drive as an ext4 file system.

However, windows does not support ext4 natively. I do have WSL and could probably mount it there but here are the issues.

Another user in my house will be primarily the one using obs and they are not technically inclined (or at least not linux inclined) i want them to be able to plug this device in and just press record and have it output to the drive, this was working fine with exfat but obviously once i reformat it could be an issue.

I have a few options and wanted to run it by here first before committing to the reformat.

Option 1) reformat drive to ext4. Keep it as a samba drive at all times, except when gaming, and have obs output the video to the drive over the network

-is obs capable of doing this reliably?

Option 2) reformat to ext4 and unplug drive when gaming or needing to use obs. Rig up a script to automount the drive with wsl when detected.

-will the mounted drive show up in the windows file explorer natively? Or could i at least pin its location to quick access?
-can i actually create some way for it to automount the drive with no user input required?
-ooh but the distro is on the drive to conserve the laptop's space, could present an issue

Option 3) reformat the drive as part ntfs part ext4 and then plug it in for gaming and obs?

-i believe in linux i could just add the part-uuid to fstab so it only mounts the ext4 portion or maybe i could mount both?
-would windows automatically just mount the ntfs portion?

Imo, option 1 is the best but i would like to have a fail safe in case i ever need to plug it directly to the windows machine. So realistically a hybrid of option 1 and 2 is best. Is there a better way to do this? Will any of these methods work?

I have been using linux about 4 years now and in that time i've done a bunch of installs. Lately i've been setting up luks and lvm, but each time i install a distro ive set up bodhi and nixos with this setup but the issue i have is that each time ive done it i've had to follow a guide.

For both these distros there werent official docs on how to do it but found guides on github. For both i had to try multiple guides and reinstall multiple times.

While ive learned a lot doing this i feel like i have too heavily leaned on the guides and would not be able to install it without a guide.

I understand the basic lvm commands to set up pvs, lvs, etc but for example when installing nix i had to reinstall twice because i didnt set up the preLVM setting and the luks device uuid. But if i hadnt found a guide that showed it i never would have known to do it.

What resources can you recommended to really understanding how to properly set all the different types of partitioning schemes (gpt, mbr, lvm, luks, etc, etc)