Hey guys,
How can I perform multi-version backups at the file-level from another SMB server?
Basically, I just want to pull backups from an SMB file server nightly and go back to a particular night to restore a single file of my choice.
I can’t figure out how to do this with TrueNAS Scale 24.10.
Thanks!
ZFS Snapshots. If you set up daily snapshots, you can go back as far as your snapshot retention policy allows, or you run out of server space.
Thanks, but how can I configure ZFS snapshots if the source is SMB only?
That’s because there is no built-in way to do that with any version of TrueNAS. Software on the source machine, or on a mutual client machine, would be the way to handle it–but TrueNAS has no mechanism (built-in or via app that I’m aware of) to pull files from a remote SMB server.
You’re going to have to be pretty specific about your current setup. I read it as you were backing up to the TrueNAS machine the had a pool set up with an SMB share for the back ups.
As an example, I back up my Win 10 machine data to an SMB share on my TrueNAS machine. I use ROBOCOPY on Windows to sync the files on the TrueNAS SMB share and captured any changes. I can use the file browser on Windows 10 to look at the SMB share on TrueNAS and, using the previous versions tab, see the file versions captured by the Snapshots feature on TrueNAS if there were file changes.
Got it!
Source: SMB File-Server with no ability to install apps
Destination: TrueNAS
Goal: TrueNAS pulls data and keeps track of versions as a backup
Synology’s do this well with ActiveBackup. I’m confident there’s a way with TrueNAS, but I can’t find it by searching or reviewing the documentation.
What you’re describing is the hard way to go about this. In broad brushstrokes, what you’ll need to do is script it.
sudo mount with some sensible parameters and a mountpoint.cp -a to copy and/or archive what you need to a dataset on your TrueNAS server.If you use tarballs, you can add a timestamp to the filename, e.g. foo.$(date +%s).tar.zst. If you’re using rsync or copying whole files, then you’ll need to take a filesystem snapshot or local archive after a successful copy operation.
There’s no magic bullet here. If you aren’t an admin on the source host, you likely have no other means of accessing the data than through the SMB mount. It can’t hurt to ask if they support SSH access, though, as rsync over SSH would be secure and a lot faster for incremental backups. On the other hand, I get better performance out of SMB when using jumbo frames and whole-file copies than I do out of rsync for whatever reason, especially when writing to an SMB share. Your performance characteristics may vary.
You may be able to use SyncThing. Not sure if it supports mounting SMB, or if you can mount SMB from the app config.
Darn. The problem with this method is that we need version control.
For example, with most NAS’s, when we set up backups, we just go to the GUI and pick a date, pick a folder/file, and hit restore.
Using rsync sounds like we’ll managing the versions rather than the firmware or OS of the NAS.
Is there no built-in backup solution (like actual backup solution with a date-based versioned restores) in TrueNAS? They can’t be the only NAS missing this.
I’m hoping for something native. Based on the responses here, it sounds like maybe there’s no built-in backup system.
TrueNAS is the backup target.
A common approach is to run an agent on the backup source, such as Veeam and that backsup onto TrueNAS, but you said you can’t do that.
There is a builtin versioned incremental backup system for the data that resides on TrueNAS. The target can be any system with a sufficiently modern ZFS and SSH.
Backup of clients to TrueNAS is left as an exercise to said clients.
Ok, thank you so much for the info. This is a bummer.
It sounds like TrueNAS is missing a system to backup server data, where it manages the backup rather than the source, a feature common among NASs that I assumed it had but I shouldn’t have.
Does anyone know if this feature is on the roadmap?
I’d be very surprised if it were, or if it were ever to appear in the base system.
This isn’t really true. Pure NAS systems are just network-attached file services. Your problem is that you’re doing this backwards. However, rather than criticize, I’m pointing out that you either need to push data for your “system of record” to your TrueNAS backup target, or pull data using the tool of your choice from an SMB mount.
Since TrueNAS isn’t a pure NAS, you can install any backup software you like in a VM or container. But again, your data source is an SMB mount and you said you have no other access to that system, so you still have to go through the mounting process one way or another in order to create a backup.
Why don’t you have backups done from the SMB server? That’s the canonically correct way to do it. Otherwise, yes: your client-side backup from the TrueNAS side will have to manage the backups.
In further comments, you then say you want “version control.” This is also not typical backup functionality. Maybe what you really want to do is put a Git repository with LFS support onto your remote SMB share which wouldn’t invoke TrueNAS at all. Or run the TrueNAS Gitea app and run a cron job to pull binaries over the SMB mount into Git and auto-commit every 10 minutes, hourly, daily, or whatever.
Fundamentally, this isn’t a gap in TrueNAS capabilities. It’s just an X/Y problem where you’re trying to do something with an atypical use case and insufficiently refined success criteria, and don’t want to use the capabilities available. I don’t mean to sound snarky, but Unix and Linux admins have been backing up with rsync and tarballs for decades. You have plenty of other options, too.
You can even backup to LTFS from TrueNAS or another SMB client, but you’re still adding an extra copying step since your real data source is on the system with the SMB-shared data. If you want version control on that data, put it into a version control system. If you want it backed up to tape, do that. If you have third-party backup software that does what you want from a client machine instead of the SMB server, TrueNAS can act as that client too.
Basically, you need to rethink what your real problem is here. It seems to me that your fundamental problem is that you want to keep using the SMB-only server as the system of record instead of exporting the data to TrueNAS and managing it from there. Maybe there’s a good reason for that, but no one on the forum can guess what that might be, so maybe you should reconsider what you’re doing. If you can’t change that basic issue, then you’ll have to accept the limitations that come with doing things that way. There is never a silver bullet, but you’ve been given roughly half a dozen ways to do what you want with your current setup. At least one of them should be “good enough.”
I appreciate the explanation.
What I’m looking for is a common feature of other NAS products.
For example, in IT, we might have a Windows File Server that shares files via SMB. We “pull” the data from that server onto a NAS (like a Synology using a built-in function). The Synology manages the backups in a calendar view, so we can restore files and folders based on the date of the snapshot.
If the Windows Server goes down, we can use the Synology to restore that data to another device, again, using a calendar view so we have excellent control over what data is being pushed back. If we rely on the source (the Windows Server), then we wouldn’t be able to restore since that server controls the backup mechanism.
It has to work the way I’m describing it, which is why most NAS products have this function. Most of my industry does it this way for the reason above.
In most deployments I know TrueNAS is the file server.
You could set up a Borg backup server as an app. It can do pull-backups from SMB.
So, you are using Active Backup for business on synology? Asustor also has a similar function. As OP indicates, not too uncommon, there are probably others.
I would think typical backup software could work for this if the share were mounted, backup, then unmount. So, duplicati, whatever. It would therefore be version controlled by whatever backup software is used.