jotrago

Perhaps I should have more correctly stated that Instant Scan only works on Windows Hosts with NTFS volumes (and NTFS Journals), and the Retrospect client installed directly on the host. NAS boxes share files use the open source SAMBA suite to present files using the SMB / CIFS protocol independently of the underlying file system. Most NAS Units run a variant of Linux and use EXT, ZFS, or BTRFS file systems under the hood, all of which are journaling file systems, but not NTFS, and hence would not work with Instant Scan. Even Windows NAS Servers ( Windows Storage Server) present their NTFS files as SMB/CIFS shares. (But of course, being Windows, you could install the Retrospect client on them and take advantage of Instant Scan because they DO use the NTFS file system under the hood) I do also admit that my approach would not reduce Volume Scan times, whereas Lennart's approach would.

AFAIK Instant Scan works only on NTFS volumes as it relies on the NTFS File System Journal. Therefore it is unlikely to work on a NAS. For your situation I would recommend the following:- Create your scripts for the specific volumes to be backed up to their own BackupSets as you have already done. For the Project folders create a Projects script targeting the whole volume, and then create Selectors to EXCLUDE the regular folders catered for by other scripts. This script will then backup ANYTHING that appears in the volume EXCEPT the regular folders. Selectors provide a very powerful method to control exactly what gets backed up. See the docs and my note here

OR Create a new Backupset on the new drive Then transfer the snapshots from the old backupset to the new one, you have the choice of transferring the entire backupset, or just the latest or selected snapshots. Update your scripts etc with the new BackupSet name. The advantage of this approach is that the entire process is done under Retrospect’s, control with logging and reporting.

As you have found, Retrospect names its tapes with a sequence number and the Backup set name. The pre-labelled tapes you have will be the barcode labels intended for use in a library or auto loader. Since you have a standalone drive with no barcode reader, the tape labels are irrelevant. I would simply get some sticky labels and relabel the tapes according to the Retrospect numbering scheme. You can add them all to the backup set in advance by inserting the tapes one by one, and clicking the ADD button, and then write the label for the name that Retrospect gives for each tape. It's a bit laborious but you only have to do it once. This scheme works perfectly for me

Many Linux distros include the Disk Usage Analyzer app. Use this to scan your intended backup folders and inspect the results for exclusion candidates

The transfer is a copy function, so the data on your source tapes will remain intact. Depending on your plans for the source tapes you may want to consider the transfer options. Transferring ALL snapshots will transfer the entire data of all 25 tapes, maybe not quite what you want. If you want to Seed a new set of tapes to use going forward, and keep the Source tapes for history, then consider transferring the most recent snapshot. This will have the effect of transferring the most recent full backup to your new backupset. You can then start adding new backups to it, and only the changes will be updated.

You might want to investigate "Transferring BackupSets" the process has options for what you want to transfer. See User guide for details on this. This would be easiest if you have two Drives, you can create a new backupset, and transfer snapshots into it. If not you would need to transfer to a disk set first, then to tape.

WINS also relies on Broadcast and on Netbios which most VPNs do not forward by default. Depending on your VPN it may be possible to configure it to allow these broadcast packets (I use a Draytek Vigor Router for my VPNs which has an option to allow BroadCast and Netbios packets to traverse the VPN. ) With Fixed Addressing the VPN server allocates the remote device an IP address when setting up the VPN, this is either done by the VPN service itself, which may have a facilitiy to set a fixed IP per devince, or otherwise they pass on the request to the Local DHCP Server, where again it may be possible to allocate a fixed address.

I think you may find it comes down to your VPNs. Most by default do not forward broadcast traffic and the default Piton Client discovery mechanism relies on broadcast. You may be able have the VPN configured to allow all or some broadcast traffic, depending on the implementation. Further your remote devices probably get allocated random addresses from a pool when they connect via the VPN, so when you specify the client manually it will work until the next reconnect when it may then have a different address, There is even the possibility of clients clashing. EG if Client A picks up address .123.123 today and backs up successfully, then tomorrow Client B connects and gets given address .123.123 then Retro is going to get very confused. You may need to investigate mechanisms to allocate your remote clients fixed addresses, eg Mac Binding in your DHCP Server. Hope this helps

Tested successfully see My Post regarding Mint 17 all still applies.

Silent Install with pubkey.dat for Automatic Client Adding Unpack the Tar, copy folder to Downloads or suitable location In the installation folder create folder public_key, add the pubkey.dat file Run the install with --silent option johng@Centaur ~/Downloads/Linux_Client_x64_11_0_0_107 $ ls Install.sh public_key RCL.tar johng@Centaur ~/Downloads/Linux_Client_x64_11_0_0_107 $ sudo ./Install.sh --silent Install Retrospect Client? (y/n): Adding RETROSPECT_HOME to system profile and login scripts...Done! Starting client as daemon... Retrospect Client for Linux started successfully! Your system appears to be compatible with the startup system used by Ubuntu and Debian. Would you like to modify rc.local to automatically start Retrospect Client for Linux? (y/n): johng@Centaur ~/Downloads/Linux_Client_x64_11_0_0_107 $ Post Installation analysis /usr/local/retrospect/client pubkey.dat rcl retroclient retrocpl

Update. Tested the 11.0.0.107 client on the newer Linux Mint 18.1 (Ubuntu 1604LTS) 64bit In a Virtual Box VM running Mint 18.1 Base And On Mint 18.1 running on my Dell 3750 i7 Laptop Everything works nicely as before

Been running smoothly for a month now. Using a ProActive script backups are running as scheduled every other day. 20 odd backups in the can, usually with no errors at all, occasionally an issue with a log file or such that had changed during the backup. Albion is the Client, Gladiator is the Server Log Samples RetroHistory Log 2016-09-07 22:07: Script "Albion" (GLADIATOR): /home, Execution completed successfully 2016-09-09 22:07: Script "Albion" (GLADIATOR): /home, Execution completed successfully 2016-09-11 22:25: Script "Albion" (GLADIATOR): /home, Execution completed successfully 2016-09-17 22:31: Script "Albion" (GLADIATOR): /home, 2 execution errors 2016-09-20 22:25: Script "Albion" (GLADIATOR): /home, Execution completed successfully RetroClient Log 2016-09-22T07:59:11: Client version is 11.0.0.107 2016-09-22T07:59:15: Multicast advertising on address: 192.168.42.198 2016-09-22T07:59:22: ipludProc: Name service listener already running. retroclient.log.0.log 2016-09-20T08:15:23: Client version is 11.0.0.107 2016-09-20T08:15:28: Multicast advertising on address: 192.168.42.198 2016-09-20T08:15:39: ipludProc: Name service listener already running. 2016-09-20T22:25:17: Log: 2016-09-20 22:25: Script "Albion" (GLADIATOR): /home, Execution completed successfully

This is true, but there it is.

You cannot delete stuff you DONT want out of a tape backup set. Grooming ONLY works on Disk Backup Sets But you CAN transfer stuff you DO want. You don't need to know where any of the backups are. If you setup a transfer job to a new Backupset for the Snapshot(s) that you DO want to keep, Retrospect will ask for the required tapes. Once complete you can recycle the old backup set tapes, which will delete the unwanted data. Ideally this works if you have 2 tape drives, or you would need sufficient space on a Disk Backup Set to recover the wanted backups, and then transfer them again back to tape.