Modify 3CX Backup Zip

[rtstech]

Hi All,

Has anyone successfully modified the 3CX zip backup file?

If I modify the contents of the zip file (unzip and then zip it again - tried several applications) the restore seems to fail.

From the logs, it looks like it is failing a signature check. I wonder if it is verifying against the "metadata" file in the zip (I could be wrong), Therefore, can't figure out how to zip it back so that 3CX accepts the zip file.

2021/02/16 19:07:43.383|17179|0001|Inf|Log is created
2021/02/16 19:07:45.905|17179|0001|Info|Restoring file test1.zip
2021/02/16 19:07:46.038|17179|0001|Info|ReadHeader() started. Position=0. Length=30669
2021/02/16 19:07:46.039|17179|0001|Info|ReadHeader() read signature. Position=38. Length=30669. Signature=test/170
2021/02/16 19:07:46.039|17179|0001|Info|ReadHeader() failed. Position=38. Length=30669
2021/02/16 19:07:46.039|17179|0001|Erro|Provided backup is not valid
2021/02/16 19:07:46.048|17179|0001|Info|Disconnecting from OM

Will appreciate any help.

Thanks,
RTS

 

[leejor]

You are probably attempting something that you should not be doing. The file, I assume, is checked to prevent restoring a corrupted file, which your modified file may appear to be.

What is it you are trying to accomplish?

 

[NickD_3CX]

I need to stress this more: You should not modify a 3CX backup

You can cause major problems to your system if you make even the slightest mistake.

 

[rtstech]

@leejor we are trying to see if we can overcome the issue with SIP trunks and Public IP being restored by the secondary of primary PBX, more details on this page.

@NickD_3CX thanks, this is the risk we may have to consider if this overcomes the problem we are having, trying to explore all avenues before we give up on Failover (SIP Trunk) or having to manually change the values on secondary every time restore happens.

 

[NickD_3CX]

@NickD_3CX thanks, this is the risk we may have to consider if this overcomes the problem we are having, trying to explore all avenues before we give up on Failover (SIP Trunk) or having to manually change the values on secondary every time restore happens.

I understand why you want to do it and I am pretty sure you are looking for a way to script this change.

My question to you is this:
Will you really trust a backup file after an unattended script has automatically edited it?

 

[Anaphylaxis]

Would it be better to restore the backup, and edit the database to change the value permanently after restore? I couldn't figure out the CRC for metadata and I doubt Nick will help us at all with the algorithm (it may be proprietary?) so I doubt we can actually modify the backup after it's been compressed due to this as the checksum won't match

 

[NickD_3CX]

Would it be better to restore the backup, and edit the database to change the value permanently after restore?

Certainly not, touching the Database has exactly the same dangers as touching the backup, one wrong turn and your passive server may never start, or even worse, start but not work correctly.

As I mentioned ins this post where all of this discussion is coming from, until we make the improvement I mentioned, Gamma is not an ideal provider to work with 3CX Failover, so maybe consider changing providers, or at least, have a backup provider for when a failover happens.

 

[rtstech]

@NickD_3CX, Yes, we are thinking of scripting it, In our case, we will have to trust the modified backup file on the secondary.

Our contingency will be the original backup files created by Primary. If there is a mistake we can always go back to the unmodified zip files, and since the modified zip will only be restored on secondary, if something goes bad with restore, the secondary will be down (risk we will have to accept).

@Anaphylaxis yes modification can be done on the database after every restore. But, if we do that we lose support from 3CX.

 

[Anaphylaxis]

we lose support from 3CX.

for what? How are they going to know you modified the db to change a value instead of submitting it from the webpage. sure it's "unofficially" supported but so is your SIP trunk so what are you telling me here lol

Certainly not, touching the Database has exactly the same dangers as touching the backup, one wrong turn and your passive server may never start, or even worse, start but not work correctly.

ok? and if the backup doesnt start you just revert the db value or restore the backup and dont run the script.. what's your point here

 

[Evolute IT]

for what? How are they going to know you modified the db to change a value instead of submitting it from the webpage. sure it's "unofficially" supported but so is your SIP trunk so what are you telling me here lol

I wouldn't play that game with 3CX. If they doubt anything has been messed with, they won't support you.

 

[Anaphylaxis]

I wouldn't play that game with 3CX. If they doubt anything has been messed with, they won't support you.

they just said the dudes sip trunk is unsupported regardless.. we have to do what we can to make our software that we pay for work for us.

 

[Evolute IT]

they just said the dudes sip trunk is unsupported regardless.. we have to do what we can to make our software that we pay for work for us.

Still, loosing support over something you pay isn't good.

I hope you don't tell that to all your customers.

 

[Anaphylaxis]

Still, loosing support over something you pay isn't good.

I hope you don't tell that to all your customers.

Frederick what are you even saying mate. I try to be supported at all times but there are some things that 3CX clearly refuse to work with so if your client needs a certain functionality you're going to need to do it for them. It's better to say "this is not supported, but we can give it a shot" than "no".

 

[Evolute IT]

Frederick what are you even saying mate. I try to be supported at all times but there are some things that 3CX clearly refuse to work with so if your client needs a certain functionality you're going to need to do it for them. It's better to say "this is not supported, but we can give it a shot" than "no".

I am simply stating that recommending to someone to go an unsupported route is never a good thing whether necessary or not.

In many cases, if you needed to go unsupported on that level (database), just go with another software since 3CX will never support someone who accesses the DB.

My simple problem with that is that: it makes the whole system unsupported, not just the little changes or plugins you used. If only it was only that!

 

[Anaphylaxis]

I am simply stating that recommending to someone to go an unsupported route is never a good thing whether necessary or not.

In many cases, if you needed to go unsupported on that level (database), just go with another software since 3CX will never support someone who accesses the DB.

My simple problem with that is that: it makes the whole system unsupported, not just the little changes or plugins you used. If only it was only that!

Frederick I agree but in this situation we are talking about restoring a failover and it has the wrong IP in the field. In this case I would rather the failover have a high chance of working by modifying the DB, even though it may be "unsupported" because if I need support guess what? I'll restore the original backup and it will be as if I hadn't touched anything. Closing down the system and saying "oh don't do that it's not supported!" is dangerous and a slippery slope.

 

[Evolute IT]

Frederick I agree but in this situation we are talking about restoring a failover and it has the wrong IP in the field. In this case I would rather the failover have a high chance of working by modifying the DB, even though it may be "unsupported" because if I need support guess what? I'll restore the original backup and it will be as if I hadn't touched anything. Closing down the system and saying "oh don't do that it's not supported!" is dangerous and a slippery slope.

Agreed. But I fear that this setting is probably not a single column easy to edit with an UPDATE SQL. It could be in a JSON or (sadly) XML format in a column. It becomes trickier at that point.

I stick to my initial opinion that: this field should be parameterable. Not static.

 

[Anaphylaxis]

Agreed. But I fear that this setting is probably not a single column easy to edit with an UPDATE SQL. It could be in a JSON or (sadly) XML format in a column. It becomes trickier at that point.

I stick to my initial opinion that: this field should be parameterable. Not static.

you're funny pal, like this makes a difference. you read the input, parse it and write the output. if you know what you're doing it's not hard at all. this field should definitely be 'parameterable', and they need to open access to the api again and officially support it. ridiculous we can't make adjustments our clients need with ease with our own tools