sdub

Copied flash to a big old Sandisk Cruzer Glide I found in the bottom of my sock drawer. Voila! Back online. Thanks. It's interesting that it was too corrupt to boot off of, but just fine for copying files to a new drive. Hopefully it lasts at least a year in case I need to replace it again. I can't believe that Samsung Fit Plus died sometime between 12-18 months. Seriously people, Don't use those little stubby USB drives! I guess that's the problem with only rebooting every 6 months... no idea if latent failures are lurking. My new best practice is to perform a reboot before I do any service or upgrades on the hardware. Make sure it all comes back up cleanly to rule out the new stuff causing problems.

I was able to get the diagnostic file off the RAM drive using another USB disk. I'll try plugging the flash drive into another port. It's the internal USB port on the Mobo... the one I've always used. tower-diagnostics-20220221-1307.zip

My Unraid system (X9DRH-7F mobo) has been running smoothly for 1.5 years. It has onboard dual GbE and a dual 10GbE NIC installed. I powered down for the first time in 6 months to replace my PCIe NVM riser card with a dual NVMe card. Long story short, my mobo doesn't support bifurcation. Oh well. I removed the card and reinstalled the old single NVMe riser that has worked since the initial build. Now when I boot, NONE of the network cards are appearing and I'm getting a dummy IP address. Furthermore, when I log in as root, I'm not prompted for a password, and it says "root@Tower" at the login prompt. When I go to /boot I don't see the flash drive.. just some RAM filesystem with few files in it. I tried running "diagnostic" but the file that it writes to the /boot/logs directory isn't there when I pull the USB drive. If I boot to GUI mode the web browser gives a 404 error on localhost. It almost seems like it's all stemming back to a problem with the flash drive not mounting properly at the start. Any help where to start?? In the meantime, I'm going to try to make an Ubuntu boot USB to see what that does.

I opened an issue on the maintainer's github project. We'll see what they say. https://github.com/borgmatic-collective/docker-borgmatic/issues/98

This is what I’ve done… I have 2 Unraid servers that back up to each other. The backups are initiated from within docker containers but connect to borg binaries that I installed natively to Unraid using the nerd pack. Unfortunately the b3vis docker container does not include an SSH server, only the client. Without that I’m not sure there’s a way for the remote machine to access the borg binary inside the local docker or Vice versa.

You need to manually initialize the repo as described here: https://torsion.org/borgmatic/docs/how-to/set-up-backups/#initialization You can either follow my configuration guide in the first post in this thread or go right to the source for help with the config files: https://torsion.org/borgmatic/docs/reference/configuration/ I think Borg is a great solution for any backup needs. I currently have it running backups: 1. From my Unraid array to a local backup drive 2. From my Unraid array to a remote Unraid server 3. From a windows PC running the Docker Borgmatic image 4. From a windows PC running borgmatic under WSL2 5. From a Macbook running Vorta All of them are running very reliably. Unless you're using Vorta, you have to be willing to mess with text-based config files, but it's really not that complicated. I've gotten a Vorta docker container to run under Unraid, but I'm hesitant to publish it to the CA appstore since I don't actively use it. I'm not really a developer, just an enthusiastic user!

Docker containers are by design minimal and not full Linux distros. You could open an issue with the container manager (https://github.com/borgmatic-collective/docker-borgmatic) and see if they’re willing to add it. I can think of several alternatives. Probably the simplest would be to invoke the command on the Unraid host via ssh. replace: findmnt /mnt/removable > /dev/null || exit 75 with: (where 192.168.1.100 is your Unraid server IP) ssh [email protected] findmnt /mnt/disks/borg_backup > /dev/null || exit 75 in your borgmatic config file and you should be in business. If you haven't already, you will need to set up keyfile authentication with the Unraid host, so it doesn't ask for a password.

I don't control the underlying docker container, so I can't add logrotate, but it does include syslogd right now. I'm not experienced with this, but I think you can use that to manage local rotating logs, or send them to an Unraid syslog server

To be honest, I think I just copied the PATH statements from an example, and never messed with it. It might not be strictly necessary, but note that cron runs as root, but not with the full root environment. So if you have before backup or after backup hooks in your borgmatic config, they might fail to run without explicitly giving the path. By default, borg/borgmatic just log their output to the console. the "2>&1" at the end of the line redirects error output to the console. In our Unraid Docker setup, these logs are viewable in the docker log window. Recently, I decided I wanted proper logfiles, so I added the following to my docker config: Then I changed my cron command as follows: /usr/bin/borgmatic -v 1 --files --stats > /mnt/logs/backup-"`date +"%a-%H"`".log I perform backsups 2x daily, so this creates rolling logfiles named like: backup-Mon-01.log backup-Mon-13.log backup-Tue-01.log backup-Tue-13.log ... Note that you could also use a date code formatted like `date +"%Y.%m.%d-%H"` and you'd get logfiles like: backup-2022.01.11-01.log backup-2022.01.11-13.log backup-2022.01.12-01.log backup-2022.01.12-13.log ... and your log directory would just grow indefinitely. Also note that I removed the 2>&1 from the end of the command. This way the borg/borgmatic output is logged, but the errors are also shown on the docker log, which makes monitoring easier. I should probably update the docker template and description to make this the default behavior at some point.

@nas_nerd Yes! If you add multiple repos to one config file, they will run sequentially but be identical. What you want is to have multiple config files, one for each repo, both located in the Borgmatic config directory. They’ll still run sequentially but you can configure each repo however you like. No need to have two Borgmatic containers. You can even use include files to avoid duplicating settings common to both files. See the support article for more detail: https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/ Sent from my iPhone using Tapatalk

I think it’s generally a better practice to create separate repos and not replicate them. It doesn’t take much longer and avoids propagating corruption or errors. see the official borg FAQ on this point: https://borgbackup.readthedocs.io/en/stable/faq.html

I installed the "neofetch" application using the Nerd pack but was bummed to see that Unraid wasn't supported as a detectable OS. I couldn't find one anywhere else, so I created my own: To replicate this you simply need to do the following: Install Nerd Pack from CA Appstore Install "neofetch" package Copy the attached "config.conf" and "unraid_ascii.txt" to ~/.config/neofetch If you want this to display automatically at login, add the line "neofetch" to the bottom of ~/.bash_profile unraid_ascii.txt config.conf

It would be great to have an option to specify the number of visible dockers in the container/VM preview. It seems hard-coded at 5. For wide screens, you could easily fit more if you wanted to.

Yeah I just used xfs…. It’s not as universal as FAT but it’s still pretty universal and there are ways to mount an xfs partition under windows if you had to.

Funny you mention that, because I was just thinking about this "issue" earlier this week... of course an extra backup isn't really an "issue", just wasted space. I've slowly moved almost all of the content I care about off the computers on the network... they almost exclusively access data stored on the Unraid NAS or via Nextcloud, which makes this issue largely go away. The one exception is Adobe Lightroom... that catalog really wants to be on a local disk. I just set up Borgmatic in a Docker container under Windows to backup the Lightroom and User folders from my Windows PC to an Unraid share that is NOT backed up by Borg (pretty easy and works great). If I include that share in my Unraid backup, I'll have way more copies of the data than I really need. Don't need an incremental backup of an incremental backup. I think I'm moving away from the "funnel" mentality. Instead I'll have Unraid/Borg create local and remote repos for its important data. I'll have Windows/Borg create local and remote repos for it's important data. The Windows "local" repo will be kept in an un-backed up Unraid user share or the unassigned drive I use for backup. Going forward, I'll probably do the same on any and all other PC's that have data I care about. The reality is that all of my other family members work almost exclusively out of the cloud (or my Unraid cloud), so there's very little risk of data loss.

The point was independence... you don't want a problem with your array making the data and the backup both corrupt. As long as you're backing up to a 3rd offsite location, the risk is realistically pretty low. You could specifically exclude the disk from all of your user shares and disable cache writes to minimize exposure to an Unraid bug, but the parity writes will slow down the backups which can take several hours for a multi-terabyte backup.

Thanks for the heads up... I'll take a look. It's too bad that b3vis has fallen behind on versions. Is there a specific feature in 1.5.13+ that you're looking for, or just don't want to fall behind the latest version too far? This modem7 fork is brand new, so I might not jump ship just yet... definitely something to keep an eye on.

Probably a question for the borg forum like you said, but it could be several things when encryption is on. Some encryption modes are faster than others, and it could be Docker throttling CPU or memory usage that is the root cause of the bottleneck, even if the host isn’t pegged at 100%. Also the encryption is single threaded probably so your overall CPU utilization might not be representative if a single core is at 100% have you tried creating a test repo with no encryption for comparison?

I've been having similar issues... for some reason, the docker image never updated from 19.0.3 automatically from the Unraid docker dashboard. I just went through a process to update to 22.0.0... I'll explain below. I found that these issues were usually because I didn't give Nextcloud enough time to start. Watch the logfile for the following line before trying to execute occ commands. [cont-init.d] 01-envfile: exited 0. Didn't scour through all 199 pages of this support thread, but here was my solution... it doesn't want to upgrade more than one major version at a time, so do just that... one major version at a time. Basically, I followed the instructions in the stickied post, option 3, except for the version change indicated below: ##Turn on maintenance mode docker exec -it nextcloud occ maintenance:mode --on ##Backup current nextcloud install docker exec -it nextcloud mv /config/www/nextcloud /config/www/nextcloud-backup ##Update to latest v19 docker exec -it nextcloud wget https://download.nextcloud.com/server/releases/latest-19.tar.bz2 -P /config docker exec -it nextcloud tar -xvf /config/latest-19.tar.bz2 -C /config/www ##Copy across old config.php from backup docker exec -it nextcloud cp /config/www/nextcloud-backup/config/config.php /config/www/nextcloud/config/config.php ##Now Restart docker container docker restart nextcloud ##Perform upgrade docker exec -it nextcloud occ upgrade ##Turn off maintenance mode docker exec -it nextcloud occ maintenance:mode --off ## Now Restart docker container docker restart nextcloud After updating, you should go into Nextcloud /settings/admin/overview page and address any security & setup warnings that are found before proceeding. Then repeat the whole process except changing this step: ##Update to latest v20 docker exec -it nextcloud wget https://download.nextcloud.com/server/releases/latest-20.tar.bz2 -P /config docker exec -it nextcloud tar -xvf /config/latest-20.tar.bz2 -C /config/www address any warnings as above, Then repeat the whole process except changing this step: ##Update to latest v21 docker exec -it nextcloud wget https://download.nextcloud.com/server/releases/latest-21.tar.bz2 -P /config docker exec -it nextcloud tar -xvf /config/latest-21.tar.bz2 -C /config/www address any warnings as above, then finally repeat with the steps as indicated in the sticky to get to v22: ##Grab newest nextcloud release and unpack it docker exec -it nextcloud wget https://download.nextcloud.com/server/releases/latest.tar.bz2 -P /config docker exec -it nextcloud tar -xvf /config/latest.tar.bz2 -C /config/www Once everything is working, you can remove the downloads and backup folders: ##Remove backup folder docker exec -it nextcloud rm -rf /config/www/nextcloud-backup ##Remove ALL Nextcloud tar files docker exec -it nextcloud rm /config/latest*.tar.bz2

You’ll need to be able to SSH from the Docker container into the remote server with SSH keys (no password). Then you can init the remote repo with: borg init user@hostname:/path/to/repo Where /path/to/repo is on the remote machine. Note that the remote server needs to have borg installed since the commands get executed remotely. In the case where you have no local repo, just this remote one, you can leave that path variable blank or delete it from the Docker template. I’d encourage you to have both a local and remote backup though… as they say, one is none! Sent from my iPhone using Tapatalk

That’s the local path in Unraid where you want the borg repo to live. It can be inside your array or on a dedicated volume. It gets mapped into the /mnt/borg-repository folder INSIDE the Docker container. Once you open an SSH shell inside the Docker container you’ll initialize with a command like borg init --encryption=repokey-blake2 /mnt/borg-repository Regardless of the location you chose for the repo outside of Docker. Once you initialize with this command, you should see the repo files in the location you put in the "Borg Repo (Backup Destination):" variable. Sent from my iPhone using Tapatalk

Another reason I chose not to use the CA backup is that it didn’t allow for de-duplication with large zip files. It made my Borg archive grow and grow. Sent from my iPhone using Tapatalk

As others have said the issue is with the file-based databases like SQLite that many dockers employ. There’s a small chance that the backup will not be valid if it happens mid-write on a database. I don’t like stopping Docker to do backups and prefer to have it be part of my continuous Borg backup however so my approach is: 1. Wherever possible opt for Postgres or some other database that can be properly backed up in Borg. 2. The backup is probably going to be ok unless it happens to occur mid-write on the database. 3. If this does happen and I need to restore, the odds of successive backups both being corrupt is infinitesimal. That’s the advantage of rolling differential backups. 4. Most Docker applications that use SQLite databases have a built-in scheduled database backup functionality that’s going to be valid. I make sure to turn this on wherever I can (Plex, etc.) and make sure that backup path is included in the Borg backup. I think with these multiple lines of defense, my databases are sufficiently protected using Borg backup, not using CA backup, and not stopping the Docker containers. If anyone sees a flaw in this logic I’d really like to know! Sent from my iPhone using Tapatalk

The specific reason for your error appears to be that "/mnt/borg-repository" doesn't exist in the environment where you're running the borgmatic command. Everything should be done from within the borgmatic container... as a matter of fact you don't even need to install the nerdpack borg tools at all in Unraid. This docker container is the only thing you need. The whole point of this CA package was to allow you to keep a "stock" Unraid installation, which does not include borg or borgmatic.

There are hooks in the Borgmatic config file for “before_backup” and “after_backup” that could be used to invoke an SSH command to tell the Unraid parent to mount/unmount volumes. For example (where Unraid's IP is 192.168.1.6) before_backup: ssh 192.168.1.6 mount /dev/sdj1 /mnt/disks/borg_backup after_backup: ssh 192.168.1.6 umount /mnt/disks/borg_backup