I make BTRFS backups of home And transfer them to external drive with btrbk or other scripts in case on an atomic distribution. So far working perfectly
That’s an excellent setup! 😊 Btrfs is fantastic for creating snapshots, and combining it with btrbk or scripts for transfers adds a lot of flexibility. Using it with an atomic distribution sounds like a smart way to ensure reliability. Have you encountered any challenges with this approach, or has it been smooth sailing so far?
I didn't really get what btrbk is doing.. maybe somebody can answer these questions?! o) Thank you! o) 1) It is meant for backing up existing btrfs snapshots (and not regular files) to.. let's say another machine called "backup-server", right?! 2) Can I access individual files from these remotely stored snapshots located on "backup-server"? 3) If not, is this the reason I make use of btrfs snapshots locally, to more easily access individual files from these snapshots? 4) I think that using snapshots locally and using btrbk to export them, takes up twice the disk space, doesn't it? 5) I would think, that if I don't want to create and store snapshots locally AND remotely, I could also just sync my data to "backup-server" with rsync, which runs the btrfs snapshots on its (remote) file system only. If yes, what disadvantages would this have compared to creating local snapshots and exporting them with btrbak? Thanks again! o)
Great questions! Let me break it down step by step to clarify how btrbk works and address your points: 1) Backing Up Snapshots: Yes, btrbk is mainly for backing up existing Btrfs snapshots, typically to another location like a 'backup-server.' It automates creating, sending, and managing these snapshots, making it very convenient for remote backups. 2) Accessing Files on Backup-Server: If the snapshots are sent as Btrfs snapshots to the backup-server, you can mount the remote filesystem and access individual files from those snapshots. However, this depends on how the backup is set up and if the remote server supports Btrfs operations. 3) Local Snapshots for Easy Access: Correct! Keeping local snapshots allows you to quickly access previous versions of files without needing to connect to the remote server. This can save time when retrieving recent backups. 4) Disk Space Usage: Not necessarily. Snapshots are lightweight since they only store changes (not full copies of files). However, when you send them to another machine, it might look like you're duplicating data, but Btrfs's efficiency usually keeps disk usage reasonable. 5) Rsync vs btrbk: Using rsync is a valid approach if you don’t want local snapshots. However, rsync doesn’t preserve the Btrfs snapshot structure-it just syncs files. This can make it harder to track historical changes or roll back to a specific snapshot. With btrbk, you get versioning and consistency, which are the main advantages of using Btrfs snapshots. Here are the links to btrbk on github and its official website for more information: github.com/digint/btrbk , digint.ch/btrbk I hope this clears things up! If you have more questions, feel free to ask!
@@TheLinuxLighthouse there were some issues back in the day when the script was in heavier development and I was running Arch Linux. The issues were related to not deleting the incremental backups or snapshots according to the rules set in the .config file or not transfering snapshots to the backup drive. But now as there probably isn’t much to develop the program just does its work as it should.
Thanks for sharing your experience! 😊 I can imagine how frustrating those issues must have been, especially on Arch Linux where things can change so quickly. It’s really nice to hear that btrbk has matured and now just works as it should. A stable and reliable backup tool makes all the difference!
Thank you for sharing your experience! 😊 Borg is indeed an excellent choice, especially with its deduplication and encryption features. Backing up to a NAS is such a practical use case! Vorta is a great GUI option to simplify Borg for those who prefer a graphical interface-thanks for mentioning it! Do you use Vorta for all your backups, or do you mix it with the command line?
That's a solid setup! 😊 Vorta is perfect for simplifying backups on desktops, especially on Tumbleweed, while pure Borg shines on servers with its flexibility and scripting capabilities. It sounds like you've got the best of both worlds! Do you find any features in Vorta that make it a must-have for your desktop systems?
@@TheLinuxLighthouse For me its just GUI for Borg, I think that for desktop usage Vorta is enough but I didn't find any features that was missing for me on Tumbleweed
That's a great point! Vorta really shines as a straightforward GUI for Borg, especially for desktop use. It’s awesome to hear that it meets all your needs on Tumbleweed without missing features. It’s always great when a tool just works seamlessly!. Thanks a lot for the insights.
Thank you for your suggestion! 😊 I’ve already created a detailed video about firewalls on openSUSE, covering everything you need to know. You can watch it here: th-cam.com/video/drH21ix7ZnU/w-d-xo.html. Let me know your thoughts after watching, and feel free to share any specific topics you'd like me to dive deeper into!
You’re absolutely right-some tools do have a more complex syntax that can feel inconvenient at first. If you’re referring to Borg, I completely agree, but thanks to the others who commented here, we’ve learned about Vorta, a fantastic GUI for Borg that makes things much easier. It’s great to see the community sharing helpful tips!
@@TheLinuxLighthouse Yes I saw it, I usually read all the comment before posting. I was thinking about mange borg on a remote machine via ssh... I got the same feeling trying NixOS 😅 Do you know what I mean? 😁
I make BTRFS backups of home And transfer them to external drive with btrbk or other scripts in case on an atomic distribution. So far working perfectly
That’s an excellent setup! 😊 Btrfs is fantastic for creating snapshots, and combining it with btrbk or scripts for transfers adds a lot of flexibility. Using it with an atomic distribution sounds like a smart way to ensure reliability. Have you encountered any challenges with this approach, or has it been smooth sailing so far?
I didn't really get what btrbk is doing.. maybe somebody can answer these questions?! o) Thank you! o)
1) It is meant for backing up existing btrfs snapshots (and not regular files) to.. let's say another machine called "backup-server", right?!
2) Can I access individual files from these remotely stored snapshots located on "backup-server"?
3) If not, is this the reason I make use of btrfs snapshots locally, to more easily access individual files from these snapshots?
4) I think that using snapshots locally and using btrbk to export them, takes up twice the disk space, doesn't it?
5) I would think, that if I don't want to create and store snapshots locally AND remotely, I could also just sync my data to "backup-server" with rsync, which runs the btrfs snapshots on its (remote) file system only. If yes, what disadvantages would this have compared to creating local snapshots and exporting them with btrbak?
Thanks again! o)
Great questions! Let me break it down step by step to clarify how btrbk works and address your points:
1) Backing Up Snapshots: Yes, btrbk is mainly for backing up existing Btrfs snapshots, typically to another location like a 'backup-server.' It automates creating, sending, and managing these snapshots, making it very convenient for remote backups.
2) Accessing Files on Backup-Server: If the snapshots are sent as Btrfs snapshots to the backup-server, you can mount the remote filesystem and access individual files from those snapshots. However, this depends on how the backup is set up and if the remote server supports Btrfs operations.
3) Local Snapshots for Easy Access: Correct! Keeping local snapshots allows you to quickly access previous versions of files without needing to connect to the remote server. This can save time when retrieving recent backups.
4) Disk Space Usage: Not necessarily. Snapshots are lightweight since they only store changes (not full copies of files). However, when you send them to another machine, it might look like you're duplicating data, but Btrfs's efficiency usually keeps disk usage reasonable.
5) Rsync vs btrbk: Using rsync is a valid approach if you don’t want local snapshots. However, rsync doesn’t preserve the Btrfs snapshot structure-it just syncs files. This can make it harder to track historical changes or roll back to a specific snapshot. With btrbk, you get versioning and consistency, which are the main advantages of using Btrfs snapshots.
Here are the links to btrbk on github and its official website for more information: github.com/digint/btrbk , digint.ch/btrbk
I hope this clears things up! If you have more questions, feel free to ask!
@@TheLinuxLighthouse there were some issues back in the day when the script was in heavier development and I was running Arch Linux. The issues were related to not deleting the incremental backups or snapshots according to the rules set in the .config file or not transfering snapshots to the backup drive. But now as there probably isn’t much to develop the program just does its work as it should.
Thanks for sharing your experience! 😊 I can imagine how frustrating those issues must have been, especially on Arch Linux where things can change so quickly. It’s really nice to hear that btrbk has matured and now just works as it should. A stable and reliable backup tool makes all the difference!
For me Borg is the best way to backup, I can backup to my NAS with ease. Also you have GUI app for Borg called Vorta
Thank you for sharing your experience! 😊 Borg is indeed an excellent choice, especially with its deduplication and encryption features. Backing up to a NAS is such a practical use case! Vorta is a great GUI option to simplify Borg for those who prefer a graphical interface-thanks for mentioning it! Do you use Vorta for all your backups, or do you mix it with the command line?
@@TheLinuxLighthouse now on all my tumbleweeds I'm using only vorta directly, but on some of servers there is still pure borg
That's a solid setup! 😊 Vorta is perfect for simplifying backups on desktops, especially on Tumbleweed, while pure Borg shines on servers with its flexibility and scripting capabilities. It sounds like you've got the best of both worlds! Do you find any features in Vorta that make it a must-have for your desktop systems?
@@TheLinuxLighthouse For me its just GUI for Borg, I think that for desktop usage Vorta is enough but I didn't find any features that was missing for me on Tumbleweed
That's a great point! Vorta really shines as a straightforward GUI for Borg, especially for desktop use. It’s awesome to hear that it meets all your needs on Tumbleweed without missing features. It’s always great when a tool just works seamlessly!. Thanks a lot for the insights.
please write a video about firewall❤❤❤
Thank you for your suggestion! 😊 I’ve already created a detailed video about firewalls on openSUSE, covering everything you need to know. You can watch it here: th-cam.com/video/drH21ix7ZnU/w-d-xo.html. Let me know your thoughts after watching, and feel free to share any specific topics you'd like me to dive deeper into!
I wonder what the point is in implementing such an inconvenient syntax.
You’re absolutely right-some tools do have a more complex syntax that can feel inconvenient at first. If you’re referring to Borg, I completely agree, but thanks to the others who commented here, we’ve learned about Vorta, a fantastic GUI for Borg that makes things much easier. It’s great to see the community sharing helpful tips!
@@TheLinuxLighthouse Yes I saw it, I usually read all the comment before posting. I was thinking about mange borg on a remote machine via ssh... I got the same feeling trying NixOS 😅 Do you know what I mean? 😁
Got it, and I completely understand what you mean! 🤣🤣🤣