On 09/06/14 01:55, Phil Stracchino wrote:
> On 06/08/14 06:09, Steven Haigh wrote:
>> I do believe this is one of the biggest shortcomings of Bacula...
>> The fact it is job based vs file based removes a lot of
>> flexibility.
>
>> If I understand things properly, for a VirtualFull will: 1) Requir
Quoting message written on Saturday 2014-06-07 13:22:33:
> Hello Josip,
>
> At the current time, only File daemon does encryption. So the answer to
> your question is: no we cannot do data encryption on SD->SD transfers.
> It could be an interesting project for someone though (not me, because
> I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 06/08/14 06:09, Steven Haigh wrote:
> I do believe this is one of the biggest shortcomings of Bacula...
> The fact it is job based vs file based removes a lot of
> flexibility.
>
> If I understand things properly, for a VirtualFull will: 1) Requi
I do believe this is one of the biggest shortcomings of Bacula... The
fact it is job based vs file based removes a lot of flexibility.
If I understand things properly, for a VirtualFull will:
1) Require all volumes as stated below, and;
2) Require enough space to write the entire backup out again;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
To do a VirtualFull you do need to have all backups since the last Full
or VirtualFull available.
I recommend against production use of SQLite, unless you have less than
10 machines.
Normally there is no reason why an instance of MySQL/Postg
Hi all,
The one thing I can see tripping me up is that from what I understand,
for a VirtualFull I will need access to ALL jobs since the last
VirtualFull. In the case of a removable eSATA drive that won't be online
all the time, I can't guarantee that access will be available to that drive.
At t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I cannot help you with your overall design because I am more
effective writing new code than helping with implementations (very
important). However a couple of points, which are my personal
opini
