im sorry to say but i find this 'security' argument really 'thin' ...
its so thin that it will break before you even truely concider it.
it sounds to me like: using NAT (network addres translation) for a firewall.
-----
i may have said it allready but here to say it again, backup is for desaster recovery, and nothing should be able to interfeer with it. If that is even possible you did a verry poor job indead.
now lets clearefy what i ment earlier, - backup pc pulls data server side.
that has 2 downsides:
1. to takes a whole lot of computting power, on the server.
2. it takes al lot of bandwidt...
1: even though it may seem rather unimportand, but that is really a mistake.
backing up is more than.
serv> hé im the server, do you want a backup?
pc> euuhhh
serv> well i think im just going to get all your data>
pc> euhhhhh
the problem with this, is that the server's cpu will now have to do everything.
i/o listing (of the filesystem), getting the data (with no form of compression what so ever).
so as soon as you want to start pulling data, no advanced technolegy features can/ will be used.
but even when you finaly browsed the 'smb' sharess, and you coppied over the data, you still want one more thing to be done. - (at least i would).. that is, you want your data to be compressed a bit to save pressious dataspace on your server. mind you! compression takes a lot of computting power.
wouldn't it be better to do all of that clients side:
<server> hee im the server, and its time to do a backup,
<client> oh okey mr server, hang on im going to do a bit of work now,
<client> here is the file mr. server i compressed it allready, so mr. router wont be mad this time its now only 1.3gb (instead of 10gb)
----