jotrago
-
Content count
146 -
Joined
-
Last visited
-
Days Won
12
Posts posted by jotrago
-
-
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
-
1
-
-
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
-
2
-
-
Tested successfully see My Post regarding Mint 17 all still applies.
-
1
-
-
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 $ lsInstall.sh public_key RCL.tarjohng@Centaur ~/Downloads/Linux_Client_x64_11_0_0_107 $ sudo ./Install.sh --silentInstall 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 usedby Ubuntu and Debian. Would you like to modify rc.localto 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 successfullyRetroClient 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.
-
If your objective is to keep one or more specific backups on a tape set, and remove the others, then a different approach is needed.
Create a new backup set, Then TRANSFER the backups you want to keep.
Then delete or recycle the original backup set and tapes
-
Retrospect has a selector with a default set of exclusions for windows.
I set about creating one for Ubuntu Linux Workstations.
I found this very useful article on AskUbuntu, and used it as my base.
This is my Exclusion list, you may well need to tune it a bit for your own situation
Folders
.gvfs
.cache
*.Trash*
*trash*
.thumbnails
.dropbox and / or your favourite Web Storage(s)
/tmp/
Folders &/ Files
cache*
thumbnails*
Files
*.backup*
*~
*Thumb.dbSelector File Attached
-
1
-
-
I finally got round to testing the new(ish) 64Bit Native Linux client on my Mint 17.3 (Ubuntu 14.04) Workstation.
It works well, and here are my detailed results
20160730 Retro Client Linux 11.0.0.107 - Retrospect MultiServer 11.0.1.106 on Win XP 32
Tar Package containing an install.sh script and a .rcl package
INSTALLER SCRIPT ANALYSIS
Open Install.sh in gedit
Requirements
Logged in as Root or Run Install.sh as SUDO
/usr/local must exist
Installation folder /usr/local/retrospect/client
Handles Upgrades - Checks for existing client
Supports the Client Public Keys for Automatically adding clients
Place keys in /usr/local/retrospect/client/public_key/pubkey.dat
Installs Man & Info Pages
/usr/local/man/man1.retroclient.*
.usr/share/info/retroclient.info.gz
Locations
CLIENTDIR=/usr/local/retrospect/client
STATEFILE=/var/log/retroclient.state
EXCLUDEFILE=/etc/retroclient.excludes
PUBKEY=./public_key/pubkey.dat
Logs
/var/log/retro*
retroclient.history text
retroclient.log text
retroclient.log.0.log opens with LibreOfficeWrter
retroclient.log.1.log etc opens with LibreOfficeWrter
retroclient.state binary
retropds.log opens with LibreOfficeWrter
INSTALLATION
Unpack the Tar, copy folder to Downloads
Open Terminal in folder
sudo ./Install.sh
johng@Mint17-3Dev ~/Downloads/Linux_Client_x64_11_0_0_107 $ sudo ./Install.sh
[sudo] password for johng:
Install Retrospect Client? (y/n): y
Enter first access password:
Retype the first access password:
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): Y
johng@Mint17-3Dev ~/Downloads/Linux_Client_x64_11_0_0_107 $
UPGRADE
Unpack the Tar, copy folder to Downloads
Open Terminal in folder
johng@Mint17-3Dev ~/Downloads/Linux_Client_x64_11_0_0_107 $ ls
Install.sh RCL.tar
johng@Mint17-3Dev ~/Downloads/Linux_Client_x64_11_0_0_107 $ sudo ./Install.sh
[sudo] password for johng:
Install Retrospect Client? (y/n): Y
Adding RETROSPECT_HOME to system profile and login scripts...Done!
Starting client as daemon...
Retrospect Client for Linux started successfully!
Upgrade completed successfully
johng@Mint17-3Dev ~/Downloads/Linux_Client_x64_11_0_0_107 $
Post Installation analysis
/usr/local/retrospect/client
rcl script
retroclient
retrocpl - text control panel
/usr/local/man/man1
retroclient.1.gz
retrocpl.1.gz
/etc/rc.local
Added line "/usr/local/retrospect/client/rcl start "
/var/log/
retroclient.history text
retroclient.log text
retroclient.log.0.log opens with LibreOfficeWrter
retroclient.log.1.log etc opens with LibreOfficeWrter
retroclient.state binary
retropds.log opens with LibreOfficeWrter
OPERATION
Retroclient is started by default at boot up
It's a system process running under root, so does not show in System Monitor by Default
Set View to "All Processes"
Run retrocpl to check status
johng@Mint17-3Dev /usr/local/retrospect/client $ ./retrocpl
Server "Mint17-3Dev":
Version 11.0.0.107
back up according to normal schedule
currently on
readonly is off
exclude is off
0 connections, 0 authenticated
Check for the retroclient process
johng@Albion ~ $ ps -e | grep retro
1744 ? 00:30:22 retroclient
On Retro Server
Configure > Clients > Add
New Linux Client should be detected - ADD > Enter Password > Confirm Name > Done
Client Goes Active
Properties
General
Refresh Check connected & Speed - OK
Check Options
Volumes
Check
Configure > Volumes >
Lots of system volumes in here
Some have Icons on eg /
I set mine to Selected Volumes and Selected Home
DISASTER RECOVERY
See White Paper
https://www.retrospect.com/en/support/kb/linux_disaster_recovery
DOCUMENTATION
johng@Mint17-3Dev ~ $ man retroclient
retroclient(1) General Commands Manual retroclient(1)
NAME
retroclient - Retrospect Client
SYNOPSIS
retroclient [OPTIONS]
DESCRIPTION
retroclient is the Retrospect Client. When executed, it enables communication with a Retrospect
application running under Windows on another computer. From the Retrospect application, you can
access volumes on the client computer and back up, restore, or duplicate files. If retroclient is
run with no arguments, the client is started.
OPTIONS
-setpass
Prompt the user to set the first access password. Once set, the password can be changed from
only the Retrospect application.
-log n Set the logging level to n (default = 6). Logs are saved in /var/log/retroclient.log and
/var/log/retropds.log
--help Display help text and exit.
COPYRIGHT
Copyright 2015 Retrospect, Inc.
SEE ALSO
retrocpl(1)
Version 9.5 July 2015 retroclient(1)
johng@Mint17-3Dev ~ $ man retrocpl
retrocpl(1) General Commands Manual retrocpl(1)
NAME
retrocpl - Retrospect Client Control Panel
SYNOPSIS
retrocpl [OPTIONS] [-proactive PROACTIVE_OPTIONS]
DESCRIPTION
retrocpl is the conrol panel application for the Retrospect Client. The control panel provides a
way to view and modify the client settings. If retrocpl is run with no arguments the status of the
client is reported.
OPTIONS
-stop Shut down the client process.
-readonly [on | off]
Set the client read-only mode (default is read/write).
-exclude [on | off]
Turn on or off the processing of /etc/retroclient.excludes.
-log n Set the logging level to n (default = 6). Logs are saved in /var/log/retroclient.log and
/var/log/retropds.log.
-proactive PROACTIVE_OPTIONS
Configure the Proactive Backup options.
--help Display help text and exit.
PROACTIVE_OPTIONS
asap Request a backup as soon as possible.
normal Return to the normal backup schedule.
mm:dd:yyyy:hh:mm
Defer the backup until after the specified time.
skipdays=n
Defer backup for n days.
COPYRIGHT
© 2015 Retrospect, Inc.
SEE ALSO
retroclient(1)
Version 9.5 July 2015 retrocpl(1)
ISSUES
One installation on a Mint 17 VM did not add the start command to /etc/rc.local
Added line "/usr/local/retrospect/client/rcl start " manually
Restart
Check with retrocpl - Client running OK
-
2
-
-
Reading through the client install script, it seems to look for pubkey.dat in /usr/local/retrospect/client/.public_key.
This is the normal location for the key for windows clients to support Automatic adding of clients and encrypted backups
-
The Retro Client Linux 11.0.0.107 checks for existing client and removes it before installing
-
Catalog files can get very big, especially if you have few backupsets that remain in use for long periods between Recycling. Several Gigs and higher is not uncommon.
Consider creating separate duplication jobs for your config file and catalogs, so they are available as normal files (not a backup set) in the event of a Disaster.
See the User Guide > CH10 Management > Catalog & Config backups
and User Guide > CH10 Management > Moving Retrospect.
As you can imagine writing to the catalog files is quite intensive as the metadata for thousands of files is written in to them.
It is good practice where possible to use separate disk drives for Catalogs, Backupsets, and System / OS / Applications.
Retrospect also makes intensive use of the Windows Temp folders.
-
Generally this type of message indicates that Retrospect has run into an underlying windows OS error while performing a function.
You can check these by using the windows "net helpmsg 1001" command on the CLI.
Usually the message itself is not that helpful, in this case you will get "Recursion too deep; the stack overflowed."
However the point is that the error is in Windows. Checking the System Event log for the error may provide additional clues, as well as googling the windows error message itself. Try "event id 1001 Recursion too deep; the stack overflowed"
-
Just another point, you don't say how many LTO drives you have, but I suspect that if the system hosting the LTO Drive has the LTFS Drivers loaded to make the LTO appear in the file system, then you probably will not be able to use that drive for Retrospect Tape backups.
I would imagine that an LTO drive is mounted EITHER as a conventional Tape Drive, OR and an LTFS. but NOT BOTH
-
We had a discussion on LTFS a while back, this may shed some light
http://forums.retrospect.com/index.php?/topic/152013-writing-an-ltfs-lto-tape/
In terms of having Retrospect write to an LTFS File system, this is not recommended for Retrospect Backup Sets, but using the Duplicate function, which simply copies files from one place to another, to copy files to an LTFS file system IS supported on Retrospect 8 & later. See above discussion for details.
-
Retrospect V7 does "Progressive" backup of changed files.
SysVolInfo does indeed store Restore points amongst other NTFS related data.
Windows Backup creates large image files as you indicated
.vhd files are usually Disk Image files belonging to Virtual Machines, presumably you are using HyperV to run a VM
A first backup with Retrospect will backup all these items, and as you say the contents of the 387G drive should fit on the 465 G drive.
However on the next backup if a file has changed it will be backed up again.
EG if your VHD has changed another 118 or 273G could be backed up
Similarly if your Windows Backup has updated a file that could cause another 41 Gig to backup
Thus your 465G drive is highly likely to run out of space on the Second backup run.
Strategies:-
Do you really need to use Windows backup AND then Retrospect.
.vhd, since the VHD file will contain any changes to the VM you could get a way with keeping only on e backup Copy. Make a separate job and overwrite the backup every time.
SysVolInfo 0 Use the System Restore management and the VSS management to manage the number of Restore Points and VSS Snapshots you keep to reduce the size.
Upgrade to the latest Retrospect with has "Block Level" backups of large files whereby it only backs up the changes WITHIN the files, not the entire file. This would go a long way to solving your issues. (V7 is now really ancient and is not properly supported on Modern (W7&8 and later) OSs)
only scan specific folders
in Server, SBS and Multi Server
Posted · Report reply
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.