Simplifying Local Archive and Restore
The P5 Companion App is a versatile desktop application compatible with Windows, macOS, and Linux, designed to streamline the archiving and restoration of files from local or shared storage.
By integrating seamlessly with the Archiware P5 Archive server, it enables users to effortlessly archive entire folders to disk, LTO tape, or cloud storage through intuitive drag-and-drop functionality.
During the archiving process, original files are replaced with lightweight .P5C stub files, which can be restored by simply dragging them back into the app.
This approach ensures that archived data remains easily accessible and manageable.
Additionally, the app supports the restoration of stub files created by the now-discontinued P5 Archive App, ensuring continuity for existing workflows.
* Drag-and-drop folders from local or network storage to archive to tape, disk or cloud
* Runs on any macOS, Windows or Linux workstation computer
* Just an Archiware P5 Archive license required, no per-workstation licensing
* Archived files replaced with small ‘stub’ files that point to the original in the archive
* Restore via of drag-and-drop of stub files
* Search/browse/restore from the P5 Archive index in a web browser
Our customer wants two DDP24Ds using P5 Archiware synchronize via internet.
Archiware is built in the DDP web interface as a separate page. Archiware P5 has three applications: Backup, Archive and Synchronize.
Using Synchronize the directory tree and its content can be synchronized via an intra or also an internet connection.
These so called synchronizing jobs can be scheduled and there are several modes, which can be used.
How to set this up and use it is described in the DDP synchronize manual. In this case the customer has two sites – each with a DDP24D with Archiware Synchronize license activated, so they can synchronize both ways. Both sites ingest material and both sites do post production.
The synchronization has two goals: having a duplicate at two geographical separate sites and the ability to have more flexibility in spreading the workload.
Given the average amount of ingests per day and the average bandwidth of their internet lines we find out that synchronization over night was all that was needed.
Since we are discussing asynchronous synchronization there are two scenario’s to consider given the bandwidth between the two sites. The scenario’s are event triggered or scheduled.
In this case ingest took place at both sites but they only worked office hours. The daily amount to ingest which was done on one site was max 4TB, the bandwidth of the connection was rated at 100 MB/s (1000Mb connection)). They did not want to decide upfront which site does what.
They also saw that having both sites with the same material was also the most reliable solution. So to get 4T accross required 10 hours. So each morning both systems were identical. Remarks to make are that they did not ingest every day and it was not always 4TB.
They also used the synchronization both ways to have the results on both sites.
