Backups to Synology NAS

[veremin]

Or otherwise you can write a simple bash script that will copy corresponding logs to different location on regular basis, so that, ram disk isn't overfilled with them. Thanks.

[d.lansinklesscher]

I think there's a way to redirect the /var/log somewhere else. Same is there is a manual way to fix the free diskspace issue.

I just think it would be nice if Veeam could detect that it's running on a Qnap/Synology and solve the issue's that are currently present to make to solution more user-friendly.

Maybe even add the option to interface so that when you add a server to the Veeam infrastructure you can select a Qnap/Synology server instead of a Linux server.
This because it is really a nice and affordable solution, and running the Veeamtrasnport service on the Nas makes it usable for example as a target for a copy-job behind a slower link without the need of an extra windows server.

[Vitaliy S.]

Yes, having an ability to change logs folder should come in handy indeed. Thanks for the feedback!

[kputzlocher]

Ive come to the conclusion that my cifs backups to my synology nas just dont work and the only way i can get the to run at a proper speed is to set it up as a linux repo. Im talking 7MB/s vs 118MB/s speeds with cifs vs linux repo on a 1tb fileserver vm.

Now i have it all installed and running good but I need some help with the veeam_soap.tar editing. I have extremely limited knowledge of linux so im hoping someone could guide me in the right direction. I am able to browse through the files on the nas and i did a search for veeam_soap.tar but it didnt find anything. So where is this file located so i can extract it and make the change so it reports the repo size properly. The only veeam_soap.tar file i could find was on my windows veeam server in C:\Program Files\Veeam\Backup and Replication\Backup so is this the correct file im looking for? I was under the impression it would get installed in the linux repo server and not be transferred from the veeam server.

[kputzlocher]

As an update to this i read some previous posts a bit closer and yes the veeam_soap.tar file does reside on the veeam server. I made the modifications required and now it does recognize the proper storage space for the repo. I am a bit concerned about what else this change could affect, so maybe a veeam rep has an answer for me? Would like to see veeam patch this so the file wouldnt have to be changed manually either.

[foggy]

I am a bit concerned about what else this change could affect, so maybe a veeam rep has an answer for me? Would like to see veeam patch this so the file wouldnt have to be changed manually either.

We haven't thoroughly tested this yet, but are planning to do so and include this modification into the product.

[fafner]

Worked like a charm so far. But today I upgraded to DSM 5.1 5004... Now I'm getting the following error:

Failed to synchronize backup repository ds412plus-syno Error: Server does not support diffie-hellman-group1-sha1 for keyexchange

Any ideas?

[kputzlocher]

Looks like maybe they took out sha1 support or maybe turned it off by default? Im far from a linux person but after a bit of searching i came up with the following file maybe having something to do with what protocols are supported: /etc/ssh/sshd_config

Im running DSM 5.0 so here is my sshd_config file, maybe post yours and we can figure out a difference? Most of it seems to be commented out, so that means its default i think. Im definitely not going to upgrade until this gets figured out.

Code: Select all

#	$OpenBSD: sshd_config,v 1.82 2010/09/06 17:10:19 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options change a
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile	.ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing, 
# and session processing. If this is enabled, PAM authentication will 
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes
#UsePAM no

#AllowAgentForwarding yes
AllowTcpForwarding no
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
ChrootDirectory none
#ChrootDirectory /var/services/homes/%u
#DenyUsers admin

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem	sftp	/usr/libexec/sftp-server
#Subsystem       sftp    internal-sftp -f DAEMON -l VERBOSE -u 000
Subsystem       sftp    internal-sftp -f DAEMON -u 000
#Subsystem       sftp    /usr/syno/sbin/sftp-server -l DEBUG3

# the following are HPN related configuration options
# tcp receive buffer polling. disable in non autotuning kernels
#TcpRcvBufPoll yes
 
# allow the use of the none cipher
#NoneEnabled no

# disable hpn performance boosts. 
#HPNDisabled no

# buffer size for hpn to non-hpn connections
#HPNBufferSize 2048


# Example of overriding settings on a per-user basis
Match User root
#	X11Forwarding no
	AllowTcpForwarding yes
#	ForceCommand cvs server

[AlainRussell]

I don't think it's something that can be changed with config (probably a compiled change) - DSM 5.1 has the version of sshd below, what version is on DSM 5.0?

OpenSSH_6.6p2-hpn14v4, OpenSSL 1.0.1j-fips 15 Oct 2014

I've filed a bug with Veeam (#00673005) as Synology won't re-add SHA1 (and it's being phased out?) so hopefully Veeam can upgrade something their end.

[millardjk]

A little editing of /etc/ssh/sshd_conf on your Synology and you'll be back in business. See http://blog.millard.org/2014/11/repair- ... linux.html for full details.

[AlainRussell]

Awesome - thanks! Great I was wrong in this case

[stanthewizzard]

Yes it works like a charm

But apparently ... Veeam is not comparible with the new python version ?
No offload to the syno cpu like before 5.1

Am I the only one affected

[Mathieu]

I just checked Veeam backup V8 but unfortunatly the mount.pm file (inside veeam_soap.tar) is not changed if I compare it with the one of V7.....
(the .tar files don't seem exactly the same but I don't know the exact differences because there are a lot of files inside them)

[Vitaliy S.]

Hi Stan,

Can you please give me a bit more information on what is not compatible? We have raised this question internally, so I would appreciate if you could share as many details as possible.

Thanks!

[DominikM]

Hi

I'm preparing to migrate our backup infrastructure to Veeam v8. For that we bought 2 Synology RS3614xs+. So far I registered the DS (Diskstation) as a Linux Backup Repository and the test jobs are working fine.
Yesterday a Veeam engineer told me, that the backup job should offload some CPU intensiv tasks to the DS. But as mentioned above, I don't see any CPU load on the DS. I asume that this worked on DSM 5.0?

@Veeam
Since there is a huge demand for supporting Synology Diskstations as a Linux Target, it would be nice to bring some effort into this subject.

[Gostev]

Hi, Meier.

There are no CPU-intensive tasks on the backup repository side, your Veeam engineer is incorrect. All the heavy lifting is done by proxy servers.

We have always supported any x86 Linux-based system as a target, and Synology Diskstations is no exception. However, any system needs to meet the existing requirements for our data mover to install and work. It's not a good idea for us to modify our tried and proven Linux integration package, because while fixing Synology compatibility, we are risking with breaking the integration for tens of thousands of users currently using other Linux-based storage devices.

I think it's in Synology's best interest to fix the compatibility they have broken in their latest release, otherwise people will prefer to go with their competitors' solutions. Besides, considering the abundance of various types NAS systems and software-based storage appliances, we are really not in position to monitor and chase compatibility across such a vast range of hardware and software. The best we can do is exactly the opposite: ensure our engine always remains the same in terms of requirements from version to version.

Thanks!

[d.lansinklesscher]

Hi Gostev,

But what about issues that still exist on both Qnap and Synology like:
-Not displaying free-space
-Veeam logfiles filling the small system/ramdisk of the nas.

Are those also issues you expect Qnap/Synology to solve?

I can fully understand that you don’t want to break integration with existing linux-based storage devices. Therefore why don’t you create an extra option in the “Add server Screen” to add the a Nas that uses a different Veeam_soap that addresses the issues?
Doing it like this you don’t break any existing linux-compatibility, but you do make those boxes better/easier to use. And they are used often for small/medium solutions.

Thanks.

[Vitaliy S.]

Hi Dennis,

An issue with displaying free space on the Synology box is scheduled to be fixed in the next updates. The updated script should will be validated across other Linux distributions before we decide to release it.

Thanks!

[Gostev]

I can fully understand that you don’t want to break integration with existing linux-based storage devices. Therefore why don’t you create an extra option in the “Add server Screen” to add the a Nas that uses a different Veeam_soap that addresses the issues?

The reason is pretty simple: because it adds yet another option for us to test and support, multiplying the test cases accordingly, and reducing the quality of testing for other options correspondingly. For this reason, I always prefer to follow Occam's razor principle. Adding a separate option for each small storage vendor who decides to do "his own thing" and break what was working for years is just wrong.

Besides, I believe that with over 120'000 of paying customers, and over half a million of free edition users, Veeam is in position where most storage vendors out there want to ensure that they maintain compatibility from their side, if they want to stay competitive with other vendors. For example, look what ExaGrid did in their recent firmware (they are one of the leaders in enterprise-scale deduplication appliances). Basically, they have built a "sandbox" environment to allow our data movers to run on their storage without affecting main data processing engine. This is so much bigger effort than to just "not brake" things which have been working for years.

[d.lansinklesscher]

Ok it makes sense that you don’t want to create an option for every vendor, I was just revering to a general nas option where you can address the issues that they all have in common without worrying about breaking compatibility with other Linux servers. But the issues can also be addressed in the “Linux server” option.

They only thing I care about is that the issues are being addressed. And I think this should be an effort from both sides where you guys should be working together, because I think it’s in the interest of both sides.

You can call Synology or Qnap a small storage vendor, but the thing is that they make affordable solutions that just work for small/medium sized business. And I think there are many Veeam users that use them.

I also don’t think you can compare Exagrid with a nas vendor like Qnap Synology. For Exagrid it’s more important to maintain full compatibility with Veeam because backup/archiving is all they do. So the percentage of Veeamusers in their userbase is way higher than in the user base of Qnap, Synology or any other nas vendor.

Anyway, I really think maintaining compatibility is something both Veeam and storage-vendors should be working on together. But if your stand in this is: ”We’re Veeam and you other guys just adjust” than there’s nothing that I can do about that. But it would be very disappointing.

[fafner]

Folks,

as long as somebody out there finds a solution for such quirks and post it here, we all are fine. Thanks forum, you rock.

[millardjk]

I noted a new issue with using a Synology: if you have SSD cache attached to the volume that Veeam is going to use, the Linux blob in veeam_soap.tar will detect & recognize the size of the SSD providing the cache rather than the main volume it is caching.

'df' seems reasonable, but veeam doesn't see the 5TB, instead it sees ~260GB (which is odd; I'd have expected less than the device size)

without cache:

synology> df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 2451064 628116 1720548 27% /
/tmp 1022984 188 1022796 0% /tmp
/run 1022984 2180 1020804 0% /run
/dev/shm 1022984 0 1022984 0% /dev/shm
/dev/md2 5800282984 305732476 5494448108 5% /volume1

Same system, with cache provided by 240GB SSD:

synoback> df -P
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/md0 2451064 628240 1720424 27% /
/tmp 1022984 188 1022796 0% /tmp
/run 1022984 3176 1019808 0% /run
/dev/shm 1022984 0 1022984 0% /dev/shm
/dev/mapper/cachedev_0
5800282984 293129404 5507051180 5% /volume1

[mcdonaldb]

Can someone walk me through editing my synology to fix this issue, im trying to follow along at the link provided: http://blog.millard.org/2014/11/repair- ... linux.html

However im looking for some more guidance on how to edit the sshd_config file.

[mcdonaldb]

Wow, not sure how i figured it out, but i did, re scanned repo and now its seems to be working. i think that's the last synology update for me for a while.

[ITP-Stan]

There is no problem if you are not trying to use your synology as data mover (or proxy).

You can just use CIFS (aka smb) or iSCSI to configure a veeam backup repo.

[Mathieu]

Does someone know where the veeam logfiles are stored on a Synology NAS when it is used as a Linux repository?

I'm having an issue with Veeam 8.0 (including patch 1) where such a repository is being used as a source for another backup copy job. Somehow this job doesn't begin to transfer data and no apparent error message is shown in the Veeam backup server console (or logfiles on the veeam backup server). When I change that backup copy job so it uses a backup job as source which is located on a local repository (through SMB share) that second backup copy job works OK.

[veremin]

All required logs are stored on the backup server and can be extracted by going to Help -> Support Information -> Export logs. If you can't identify the root cause yourself, feel free to open a ticket with out support team and let them assist you with that. Thanks.

[foggy]

Make sure there is at least one restore point created within the specified synchronization interval.

[veremin]

Somehow this job doesn't begin to transfer data and no apparent error message is shown in the Veeam backup server console (or logfiles on the veeam backup server)

Isn't the same repository specified as both source and target for a backup copy job by any chance? Thanks.

[jpadgett]

Synology now supports Docker. Would there be any Devs that have an interest in putting a distributed application package together so it can be ran within a container? PRETTY PLEASE!!! I think this would be of great value! It would make it more of a turn key solution which would make Veeam just that much more appealing!!!